On 12/07/2012 08:17 PM, Mo Morsi wrote: > Aaron gave me a good idea yesterday. The script [1] which I whipped up > to demo deltacloud on fedora-devel [2] could be used to very quickly > test out templates on the cloud. (without having to wait for the long > image building process which takes lots of time and bandwidth) > > The tool is pretty basic, it just sets up a cloud environment via > deltacloud with some extra info added to the tdl (the added fields do > not overlap w/ the existing tdl ones, so the templates can still be used > with oz / imagefactory as is), and runs a ssh loop to process the tdl. > > The nice thing is I can simplify it even further very easily by removing > that ssh loop and simply using oz to process the tdl on the running > cloud instance. Essentially this would mean mycloud (the name can be > changed) is the simplest unification of deltacloud and oz > > To prevent confusion, I propose we name these templates w/ the extended > cloud data, "extended tdls", or etdl's for short. > > This would give deltacloud another use case and would make building and > testing templates for various purposes very simple and easy. Thoughts? > > -Mo > > [1] https://github.com/movitto/mycloud/blob/master/mycloud.rb > [2] http://lists.fedoraproject.org/pipermail/devel/2012-November/173298.html >
I've been talking w/ clalance over the last couple of days and it seems like changing this to use Oz on the cloud instance isn't feasible due to Oz's dependency on libvirt. Discussing this w/ him it seems the best way to move forward w/ this is to proceed as originally planned and simply manually process as much as we can from the TDL directly on an instance started w/ deltacloud. This will allow us to quickly build and test these TDLs with the goal of growing the template repo as well as the community. After the user has a rough approximation of the template, they can use the traditional imagefactory / oz tooling to perform the final build of the images. The nice thing with this is the same templates can be used for image creation as well as service/systems orchestration, a feature which I have not seen in any other cloud framework. Going forward, I'm going to refactor the existing utility a bit to make it more modular and clean (introducing a little bit of abstraction to handle for rpm-based and deb-based systems) and then packaging it up into a gem/rpm (and submitting them to their respective locations). I would also like to write some preliminary tests and docs, though that might not happen for a couple sprints. -Mo
