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
As per Mike's request, I wrote up a story encapsulating the mycloud
proposal. It can be found on the project wiki here: