You have me wondering about the feasibility of offering this as a CloudFlare app.
If I was able to throw up a little ajax/client side JS driven app at a domain, throw CloudFlare over it (like I usually do for most smaller domains I own) and then have it all happen without even needing to change that .htaccess file, then your onto something even better.
I also think the pricing model may need some work. Per page seems like it could cut you off from some potential customers. For instance, I'm already thinking of a blog engine I wanted to try out more thoroughly by making it the one i use on my new blog but wasnt prepared to loose "google-ability". I Would like to be able to use a service like this but when I do my mental math it doesn't add up. I wanted to use a blog engine that will produce a large number of pages by pulling in third party service activity into my site. So its not 100% what I want, but damn its tempting.
If your pricing it to cover costs, might I suggest looking to optimize your stack to bring down those costs down?. If you can cut the price and make it more of a 'yeah for $X its easier than doing it myself' you'll get more takers. Right now it feels that your current lowest price per month is too high for a lot of devs to decide the $ is a throwaway expense to save them time. Id hazard, below $25, and probably with an order of magnitude more pages.
All that said... I may still try it out. It looks interesting.
The repo on my local box goes by the name of "Sledge". The name is still TBD, hoping for an inspirational moment.
Its a specialized 'cloud in a box' type stack. Primary goal is to allow for scale applications that don't normally scale well inside a single machine, and scale them out until you hit the limits of your machine. Perfect examples are third party binary programs that assume you can only run one instance, or processes that need a lock on some kind of interface or file in order to function. I've had a few interested parties that want to see how it pans out.
Release... well i plan to demo it out in public for the first time while I'm at Pycon AU in Hobart (not a presenter just going to be there & showing anyone who's interested)
This is great. Now we are free to help remove dependencies, improve this engine and in the long run hopefully help Valve take further steps into being a more Open Company , I hope that Valve change the license once they are in a position to do so. They are in a staggeringly odd turn of events starting to 'Open Up ' and working within the view of the outside public on a number of high profile software projects. They are making good moves, I for one intend to encourage them to make more by helping! Pull requests to help them will make them realize they will gain more if the engine is even more open, its a matter of time.
The 50+ people that attend the event have done nothing illegal (other than possibly trespass depending on where the party is and how they get there, and anything illegal they may do while they are at the location in question)
The event organizer who may or may not have endangered all their lives in various ways from fire hazards to toxic chemical exposure to food poisoning. They have done something most would call wrong and are rightly required to submit to the rule of law for the good of the people they may cause harm to and obtain permits proving that they have met certain standards we set to avoid letting people take advantage of the public.
I'll add that I think this may be in may locations burdensome and irritating, but it is important. In the same vein as building construction standards and health inspections in restaurants are important. I do wish it was less 'red tape' but its a matter of balance. Would be nice if the guests could simply sign a waiver, but where do we draw lines? I haven't sufficient ambition to be either a lawyer or politician that I wish to try drawing these lines. I only believe that their existence is important & I know where I feel they should sit.
Yaml is a hair above "properly indenting my templates" as far as complexity goes. You write django templates, you can handle Yaml ;-)
As current 'devops guy' on a django project myself, salt works wonderfully. Salt has states available that let you setup all that software, create the virtualenv you need (including telling it you want to use the requirements.txt that you pulled down with your django project source code - Salt gives me my own little Heroku :D ) and for anything left in those wgets you can throw a block of salt cmd.run calls using specified ordering to enable them to run neatly in the sequence you desire.
As one of the people on that list who may well respond there, I'll reply here as well so its on the record.
You will be very well off if you read and 'digest' the Salt docs on States first, before moving on to modules, pillars, grains, custom returners, etc.
What you probably need to do with logrotate is take the configuration that you normaly setup on your servers, then add it to your salt system. So top.sls calls 'logrotate' running the 'logrotate/init.sls' and that has a definition that says "I want logrotate installed, I want it running as a service, and by the way take the file 'logrotate/config.conf' and shove it in /etc/logrotate.d/ as <correct filename>, p.s. If i change that file, restart logrotate"
With States & the requisite declarations to enable salt to know what order things need to be in, you shouldnt have much trouble adding a simple service like logrotate along with a specific config file to use for that service.
As a customer of the original and deliberately offensive online T-Shirt store. Who certainly never had a problem with his wares causing this level of offense until one particular case.
I cant help but think the problem here wasn't so much the offensive shirt or the content. It was that he failed to realize that putting a t-shirt that has little old ladies chuckling and moms happily wearing it, next to a tshirt that say something that only >1% would wear with pride and more than >25% may take offense at, is inviting disaster.
I doubt people even saw the shirt directly, I bet it came up as a related product while they were buying something else on his store, and the suggestion that they may want to buy this shirt based on them buying another of his shirts was likely one of the primary causes of offense "I see you like <cute cat joke shirt> I sold you. Can I recommend you snatch a copy of this handsome <culturaly satirical rape joke> as well?"
That sort of thing tends to offend people. But I dont see why he didnt apply a flamethrower of purity all over the place. New Corp-Registration, new domain, new amazon seller account, new EVERYTHING, but this time, some sanity checks in that script. A few careful letters/calls to various services to make sure they know hes legit & what hes doing is means they are keeping a valuable customer. and then a wash of shiny new design and brand all over it. Meet the New company same as the old company.
I would hazard that for a given set of axes in the multivarial formula we will call "control" for short. You definitely can be fully in control. The question is "does what I'm doing fit within the bounding space I can exert full control over.
Salt as an 'ecosystem' has capabilities that extend more into this area. Salt Cloud and the Salt Bootstrap script are 2 of the things that I feel invalidate some of the argument that tools like Salt ( I wont comment on the Chef & Puppet ecosystems ) are capable of operating much closer to your aim than you give them credit for.
For starters, I'd quit before letting a boss tell me their precious snowflake AMI was 'more stable' and I shouldnt waste any time trying to ensure I can recreate it should someone delete the image. In my own workflow, Salt is step 1 in any system. I build a stand alone salt configuration that can from bare OS image on first boot, initialize salt, and then pull the system forward to the desired state. Then for cloud roll out, the next step is to take an image of that VM/Container which I can then replicate much faster.
And one of my long terms plans is to hammer Buildbot, Salt, Salt Cloud, and a lot of time into a system that gives end to end control. Now if only I could code a decent UI for it... putting bootstrap on months of work would feel cheap lol.
Which is one of the reasons I like them as much as I do. I can watch the iterations, they work hard on their product are committed to open source, and release regularly and often.
The other big win for me is I can read their code, I understand python & have a number of items I'll be able to contribute to upstream that will help others use the product.
If I was able to throw up a little ajax/client side JS driven app at a domain, throw CloudFlare over it (like I usually do for most smaller domains I own) and then have it all happen without even needing to change that .htaccess file, then your onto something even better.
I also think the pricing model may need some work. Per page seems like it could cut you off from some potential customers. For instance, I'm already thinking of a blog engine I wanted to try out more thoroughly by making it the one i use on my new blog but wasnt prepared to loose "google-ability". I Would like to be able to use a service like this but when I do my mental math it doesn't add up. I wanted to use a blog engine that will produce a large number of pages by pulling in third party service activity into my site. So its not 100% what I want, but damn its tempting.
If your pricing it to cover costs, might I suggest looking to optimize your stack to bring down those costs down?. If you can cut the price and make it more of a 'yeah for $X its easier than doing it myself' you'll get more takers. Right now it feels that your current lowest price per month is too high for a lot of devs to decide the $ is a throwaway expense to save them time. Id hazard, below $25, and probably with an order of magnitude more pages.
All that said... I may still try it out. It looks interesting.