cloudlets

It wouldn't be the craziest thing people do with docker: http://blog.bittorrent.com/2013/10/22/sync-hacks-deploy-bitt... http://blog.docker.io/2013/07/docker-desktop-your-desktop-ov... There has been discussion of taking the git analogy further. We actually experimented with a lot of that early on (https://github.com/dotcloud/cloudlets) and I can tell you it's definitely possible to take the scm analogy too far :) I do think we can still borrow a few interesting things from git. Including, potentially, their packfile format and cryptographic signatures of each diff. We'll see! Here's a relevant discussion thread: https://groups.google.com/forum/#!msg/docker-user/CWc5HB6kAN...

Timing is definitely part of it. Being too early can kill you. If you think your idea is awesome but too early, my advice is to keep trying for as long as it takes. Docker was not my first attempt at solving this particular problem :) [1] [2] [3] [1] https://bitbucket.org/Foi3GraS/dotcloud-fork/commits/1 [2] https://github.com/dotcloud/cloudlets/commit/0af885a5266fba7... [3] https://bitbucket.org/dotcloud/vm2vm/commits/2a34438989fbff0...

That is the first thing we tried [1]... It turns out it's not super practical. In theory a root filesystem is just another set of files.. but git doesn't support posix metadata, for example. You have to wrap or hook it to preserve permissions, uid, gid, as well as unix sockets, device files etc. Half-way through your hand-made implementation of a file-metadata-serialization tool... You realize, yeah, that's basically what tar is. Another problem is that in our particular use case (tracking changes to a root filesystem) the space and bandwitdh savings of binary diffs are not worth the overhead in execution time. Downloading an image is as easy as extracting a tar stream. 'docker run' on a vanilla ubuntu image clocks at 60ms. 'docker commit' is as simple as tar-ing the rw/ layer created by aufs. How long would a git checkout of that same im

This reminds me of radmind: http://rsug.itd.umich.edu/software/radmind/ Lots of good ideas in there (some of which inspired early work on dotCloud, including https://github.com/dotcloud/cloudlets )

Ironically dotCloud started out in 2008 as a very similar project, with the same lofty goals. We had VM templating and versioning (https://github.com/dotcloud/cloudlets), cross-infrastructure deployment (https://bitbucket.org/dotcloud/vm2vm), various goodies based on container virtualization, copy-on-write filesystems (https://github.com/dotcloud/aufs.py), and an orchestration layer to tie it all together (I found an old fork at https://bitbucket.org/Foi3GraS/dotcloud). It powered various 3d-party "XaaS" throughout 2009 - here's a French provider that still seems to be alive: http://www.diva-cloud.com/softwares Then in 2010 we joined YC, and actually tested our claim that "you can make it publicly available as a service!". Within 6 months we had rewritten 100% of the codebase around the real constraints of deploying and being responsible

or is your perspective that something as simple as this https://github.com/dotcloud/cloudlets/blob/master/sample.clo... would work? Wound't the system become a nightmare once I start installing/changing stuff in the machine in a very organic way? Meaning, I'd have to go and maintain that manifest???

That's exactly what Cloudlets does. http://github.com/dotcloud/cloudlets