----- Original Message -----
From: "Hugh Brock" hbrock@redhat.com To: "Mo Morsi" mmorsi@redhat.com Cc: aeolus-devel@lists.fedorahosted.org, "Tomas Sedovic" tsedovic@redhat.com Sent: Friday, March 8, 2013 5:30:08 PM Subject: Re: Re: tdl-tools update
On Fri, Mar 08, 2013 at 11:18:49AM -0500, Mo Morsi wrote:
On 03/07/2013 07:03 AM, Tomas Sedovic wrote:
On 03/06/2013 05:34 PM, Mo Morsi wrote:
Figure I'd send around an update regarding tdl-tools [1]. I have some content to demo at our next sprint recap, and plan to make a short screencast which I will format into a blog post w/ some content:
As you may recall, tdl-tools is a set of tools to make building, testing, and deploying tdls (as used by imagefactory/oz) quick and easy.
All in all the current tools are comprised of:
- tdl-create: create a new tdl/etdl from scratch, includes an
interactive mode
- tdl-verify: verify the accuracy of your tdl on the command
line
tdl-convert: convert an tdl/etdl and vice versa
tdl-launch: start a new instance w/ deltacloud and process the
tdl on it, great for quickly testing tdl's
- tdl-apply : simple command to proxy tdl's between cloud
instance and image services, specify tdl via cmd line w/ flag indicating whether to use tdl-launch/deltacloud or imagefactory to handle the tdl.
- tdl-config: creates a new config file in the user's home dir
containing cloud credentials (which the user will be prompted for) to be used by tdl-apply to pass onto deltacloud/imagefactory
I also would like to incorporate a '--server' flag in tdl-apply to provide a simple sinatra based web-service which to also serve this proxy over http.
These commands are all currently available via the 'tdl' gem on rubygems.org [2], simply 'gem install tdl' and invoke them on the command line.
-Mo
[1] https://github.com/aeolus-incubator/tdl-tools [2] https://rubygems.org/gems/tdl
Great stuff, Mo!
Sent a small pull request your way.
Are you familiar with libosinfo[1]? Might be good to integrate it with tdl-tools.
libosinfo is a database of various VM-related metadata for each OS you might want to virtualise. So things like the preferred NIC, minimum/recommended CPU and RAM and locations of the ISO images and the like.
If tdl-tools queried this information, we could generate TDLs with defaults known to work and remove a lot of the manual work that people still have to do today.
e.g. `tdl-create fedora 18 x84_64` would spit out a template that's ready to pass to Oz. We could even take it one step further and actually send it to Oz.
Hey thanks for the patches tomas. Completely agree libosinfo would be a natural fit here, for tdl-create as well as some of the other tools. Do you know if Ruby bindings for it currently exist? We can probably look into quickly whipping them up if they do not.
I believe libosinfo is written with gobject bindings, so using it from Ruby shouldn't be a problem. Dan Berrange is the maintainer, you can ask him...
--H
That is indeed the case.
The libosinfo documentation is pretty much nonexistent at this point, but they ship with a few examples:
http://git.fedorahosted.org/cgit/libosinfo.git/tree/examples/demo.py http://git.fedorahosted.org/cgit/libosinfo.git/tree/examples/demo.js
It should work similarly with Ruby but I've never deal with GObject there before.
I'll be on a vacation next week but I'm definitely interested in looking into this and sending some patches.
Thomas
I was thinking about writing a tool that would build JEOS images based on the specified OS but it might make more sense here -- if you're interested.
What do you think?
This sounds great to me, feel free to send pull requests. I'm also down for a more lax push process w/ tdl-tools to keep things a little more agile at this early stage. We can sort it all out going forward.
Take care, -Mo
-- == Hugh Brock, hbrock@redhat.com == == Senior Engineering Manager, Cloud Engineering == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey