Open Stack

This is something we really need. Right now the 10-minute interval is
really annoying. It's unclear to me how much support we get this event
notification from the underlying virt drivers, but we'll at least play with
it with libvirt.

I recall libvirt binding doesn't use eventlet, hence no green threads. The
callback would happen in another OS thread instead. Currently libvirt calls
are also executed within a OS thread pool to prevent blocking
behavior. This will probably make implementation. For example, you can
never call logger in another OS threads otherwise eventlet would puke. So
far the only thing that seems to work is to use a pipe to communicate among
OS threads with eventlet presence as we did in python-evzookeeper package.

Thanks,
Yun

On Tue, Jan 15, 2013 at 8:24 AM, Daniel P. Berrange <berrange at redhat.com>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.
>
> 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:|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130117/4fcd9eb0/attachment.html>