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