I wonder - has anyone ever tried the approach of the entire VM binary image being the repo and doing smart bindiffs as changes? The trick would be to identify what is "code/config/program code" vs random/temp files.
In code tracking you do it manually by saying don't track. Here you'd need a bit more intelligence, but seems like doable.
And you could create then like a git for machines.
I may be too simplistic / not fully understand the stackrocket/blueprint/vagrant approach - but why not doing something radically simpler???
mmm I take your point - what ideas are out there to do that thought? I agree it is hard ...
Good news is that for the "known/commont stuff" you can always have a central database of the random/temp stuff they generate.
E.g., mysql generetes tmp files here and there, and so and so - so you could profile all that common stuff in that way.
Then the uncommon stuff or your custom things, you declaratively say "do not track" as you do with code today.
Moreover you can do it in a way that is crowdsourced - ie: if its a cloud service when people declare such and such in mongodb is random/temp then you learn for all users.
At the end of the day there is a limited number of things people use and for the long tail it is OK for people to be declarative I guess.
But on the flip side I can see how that could end up being a nightmare.
But wouldn't it be nice to do something as simple as pull/commit/push for general purpose computers?
that piece is the less difficult i think - you could always use existing VM infrastructure and do (1) restore (2) apply changes and (3) save back - I wouldn't mess with disk formats and so on - no need
I am just spitting out ideas without deep thought but a discussion might prove fruitful.
It could come down to certain types of data, some to be ignored, some to be careful of (like data or code), others to blindly overwrite (critical security updates).
The point would be treat the data as "dumb", but to keep in mind that some data are "dumber" than others.
Perhaps if we had our own disk image format, we could mark certain types of data to be ignored for instance.
Our VM would know what to mark as ignored for say POSIX systems and that aspect could be configurable.
That's nice. seems to be the infrastructure required for building such system. question is how do you come about building the manifests? Users need to do that???
In practice, most of the work happens in the base image. Future versions simply extend the manifest with a few extra lines.
Ideally you want to "compile down" to cloudlets. With smart change management tools you can make it really simple for the user. That sounds exactly like Stackrocket's cup of tea :)
You are right. It's very similar to vagrant. When we started implementing our idea, we did not know about vagrant.
The vagrant functionality is part of what we do, but we also have a hosted service and offer access control to your team. We also have a mechanism to synchronize changes between your envs
How will this work? It sounded like a user could just build a custom VM image and send it to you. There wouldn't be a way to deploy that to heroku, right?
Are you doing sort of a blended app hosting/cloud offering?
Have you seen the dotcloud "build files" for specifying services? I wonder if trying to encourage standardization among cloud/app hosts on a service specification file like this would be beneficial, similar to Gemfile/Procfile/etc.
Your homepage should definitely mention that Mac is the only supported client. Take a look at the OS statistics from the hits on your site - my guess is that most are not Mac.
Mac only really is a bummer. I realize that there's a large and vocal crowd of developers doing that, but there's also a big Windows/.NET crowd you could easily be targeting with this. Seeing this on Windows would be great, if you use the open source VirtualBox you can easily make cross platform images.
As others said, it would be good if you indicated only OS X support. I just assumed from the screencast that at least any *nix system would work. Surely making a Linux client isn't far off, though, right?
When I saw StackParts this week I was reminded about how much pain is involved in getting a particular "stack part" up and running. Nice to see a potential solution.
Love the concept. Casual use of VMs-as-if-they-were-documents is a great trend that still has a lot of potential. (StackRocket/Blueprint/Vagrant/etc could possibly benefit from a Ninite-like visual interface for bootstrapping dev/server VMs.)
A couple landing page nits:
• it'd be helpful to have some extra details/screenshots for people without flash to play the demo video
• lots of things on the landing page seem like they should be clickable to get started, but aren't. For example, 'Create a dev stack' and 'Make a stack, customize it' button-like areas. I bet using a click-analytics heatmap you'd see a lot of stray clicks on those.
That's a great idea! I'll bet chef and some elbow grease on the part of the service provider would make the ninite ideal possible for some limited subset of popular tools. This is where Turnkey Linux should be heading, too.
I have been having so many problems getting vagrant + chef-solo to do what I want to duplicate my rails dev env... Something simpler and more abstracted would be great. I want to spend my time coding, not configuring my environment.
It may just be me, but I tried clicking some emphasized text because it looks just like the links. E.g. I tried to click "or make your own..." in "Use our stacks, or make your own..."
In code tracking you do it manually by saying don't track. Here you'd need a bit more intelligence, but seems like doable.
And you could create then like a git for machines.
I may be too simplistic / not fully understand the stackrocket/blueprint/vagrant approach - but why not doing something radically simpler???