Open Stack

Hi Folks,

Sorry for being a tad slow on the uptake here, but I'm trying to understand the sequence of updates required to move from a  system that doesn't have external  events configured between Neutron and Nova and one that does  (The new nova-specs repo would have captured this as part of the BP ;-)

So assuming I start form the model where neither service is using events, as I understand it


-          As soon as I deploy the modified Nova code the compute manager will start waiting for events when pugging vifs.     By default it will wait for 600 seconds and then fail (because neutron can't deliver the event).   Because vif_plugging_is_fatal=True by default this will mean all instance creates will fail -> so that doesn't seem like a good first move (and maybe not the best set of defaults)


-          If I modify Neutron first so that it now sends the events, but Nova isn't yet updated to expose the new API extension, then Neutron will fail instead because it can't send the event (I can't find the corresponding neutron patch references in the BP page https://blueprints.launchpad.net/nova/+spec/admin-event-callback-api - so if someone could point me at that it would be helpful).    So unless Neutron can cope with this that doesn't feel like a good first move either.



If feels like the right sequence is:

-          Deploy the new code in Nova and at the same time set vif_plugging_is-fatal=False, so that Nova will wait for Neutron, but will still continue if the event never turns up (which is kind of like the code was before, but with a wait)

-          At the same time enable the new API extension in Nova so that Nova can consume events

-          Then update Neutron (with presumably some additional config) so that it starts sending events

Is that right, and any reason why the default for vif_plugging_is_fatal shouldn't be False insated of True to make this sequence less dependent on matching config changes ?

Phil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/5c7cb367/attachment.html>