Re: [openstack-dev] [nova][neutron] Changing to external 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 ? Yes, because the right approach to a new deployment is to have this enabled. If it was disabled by default, most deployments would never turn it on. Difficult to get the balance here, as I think we also have a duty to not break existing deployments. I would have preferred the initial set of defaults to be backwards compatible, with a subsequent change (say at Juno.1) to change them to the on by default Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][neutron] Changing to external events
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] Changing to external events
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) Yes, but set the timeout=0. This will cause nova to gracefully accept the events when they start showing up, but the computes will not wait for them. - Then update Neutron (with presumably some additional config) so that it starts sending events Right, after that, set fatal=True and timeout=300 (or whatever) and you're good to go. 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 ? Yes, because the right approach to a new deployment is to have this enabled. If it was disabled by default, most deployments would never turn it on. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
