[Ovirt-devel] Taskomatic Qpid Transition, LVM and Migration.

[Ian Main]

On Mon, 19 Jan 2009 09:02:46 +0100
Chris Lalancette <clalance at redhat.com> wrote:

> Ian Main wrote:
> > So, I'd like to propose that I post a new patch on Monday with
> > Chris's comments incorporated but with LVM scanning still removed so
> > that we can get some testing of taskomatic/qpid.  At that point I'll
> > make it top priority to get the LVM scanning working again properly.
> > This will likely mean a new version of libvirt-qpid that figures all
> > this out and provides a nice pointer to a volumes LVM pool making it
> > much easier for taskomatic to figure out.
> > 
> > This sound reasonable?  Chris, you ok with that?
> 
> I guess that is fine; we'll have a temporary break in functionality, but as long
> as we fix it up pretty quickly, it should be OK.
> 
> As far as getting LVM working, I actually came up with another idea that may
> work and require no changes to libvirt itself.  The basic problem with the
> current algorithm (besides the fact that it is complicated) is that
> pool.lookup_vol_by_name() works globally, not on a particular pool.  I *think*
> we could actually write a quick wrapper to that call that does the right thing;
> after all, we do have the pool already, so we can fetch all of the volumes that
> are attached, and see if *this* volume matches up with one of the ones we
> already know about.  It would have to be looked at in more detail, though.

Yeah, that may be best.  And then we can use that call from within libvirt-qpid to
build the hierarchy.  Part of the problem right now is that basically all the
lookup calls don't exist in the qpid version because the objects just come/go from
the server as they are created/destroyed and you can use the qpid lookup functions
to find whatever you need.  For that reason I actually don't know that it's possible
to implement this right now.. it needs libvirt-qpid support.

I think that's a good idea to add a new API and get this working properly.
 
> > The other sticking point is migration.  Currently we are still using
> > ruby-qpid to do the migration via libvirt.  I have spoken to the
> > libvirt folks about the creation of a split (src and dst) API to allow
> > migration to be set up over qpid but it sounds dubious.  It is also
> > likely that we will need libvirt to libvirt communications in the
> > future anyway as that is the way they are headed.
> > 
> > So for now I think we're going to need to carry the libvirt gssapi
> > configuration going forward until a better solution is found.
> 
> Just to be clear; by "libvirt gssapi configuration", you mean that you are still
> doing migration by directly connecting to dst and src on from the ovirt WUI, and
> then doing the transaction like that?  If so, that makes sense; anything else is
> going to require a lot more thought and time to implement.

Yes that's right.

New qpid rpms are pushed now, so I'm working on a patch to add gssapi support today.
Hopefully I'll post a new taskomatic patch tomorrow.


	Ian