Open Stack

On Tue, Jan 15, 2013 at 11:32:31AM -0400, Sandy Walsh wrote:
> 
> 
> On 01/15/2013 09:24 AM, Daniel P. Berrange wrote:
> > On Tue, Jan 15, 2013 at 12:04:31PM +0000, Mark McLoughlin wrote:
> >> On Tue, 2013-01-15 at 10:52 +0000, Daniel P. Berrange wrote:
> >>> The question is how to structure the processing of events. I don't
> >>> think that the hypervisor drivers should be directly processing events.
> >>> Instead I believe they need to pass along the event notifications to
> >>> the manager.py class. So my current thought is to introduce a new API
> >>> to nova.virt.api
> >>>
> >>>   register_event_notifier(self, callback)
> >>>
> >>> and have nova.compute.manager provide a callback impl to receive the
> >>> events. Before I start coding on this, I want some kind of confirmation
> >>> that this is an acceptable direction to go in, since there is no current
> >>> callback based interactions between nova.compute.manager & nova.virt.api
> >>
> >> That all sounds good to me, but can you go into more details about how
> >> the event dispatching would work?
> >>
> >> We don't have a mainloop to integrate this with, so presumably you're
> >> talking about spawning a greenthread which would poll for events (using
> >> virEventRunDefaultImpl()?) and then invoke the callbacks? Does this
> >> greenthread need its own libvirt connection?
> >>
> >> Does this new thread introduce any new concurrency issues? I guess not
> >> since processing each RPC message and running periodic timers all happen
> >> in different threads, so this wouldn't be much different.
> > 
> > Yes, thanks to eventlet awfulness, we'd need to have a greenthread running
> > the libvirt event loop.  The event notification callbacks from libvirt
> > would thus obviously execute in the greenthread. What I'm not sure about
> > is how to switch control back to the main eventlet thread before we call
> > out into the manager.py's callback.
> > 
> > I imagine a queue of events in the nova.virt.libvirt.driver object which
> > is fed back the libvirt greenthread callbacks. Something in the main
> > eventlet thread would then have to process the queue to dispatch to the
> > manager. With a regular mainloop the way you'd do this is to schedule a
> > timer to fire after zero seconds. I'm not familiar enough with eventlet
> > yet to know how you'd do this.
> 
> Sounds like a good idea. My immediate concern is what happens if we miss
> or drop the callback? How will the downstream consumers of the
> notifications get the update?

I'm not really sure what makes you think a callback could be missed
or dropped. It is just another python method call in nova-compute.
In any case the existing periodic task could still reconcille state
even if events were used.

> Beyond that, could the callback write to the rabbit queue directly,
> either as a notification or as a new RPC call?

The RPC layer isn't involved at all here. This is just about interaction
between nova.compute.manager & nova.virt.api classes which are all in the
same process.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|