Is there a chance to get rid of this vif-plugged event at all? E.g. by transitioning it to an ReST API interface? As far as I know this is the only RPC interface between neutron and nova.
-- ----- Andreas IRC: andreas_s (formerly scheuran) On Mo, 2016-06-06 at 20:25 +0900, Akihiro Motoki wrote: > Hi, > > If I understand correctly, what you need is to expose the neutron > behavior through API or something. In this particular case, neutron > need to send a vif-plugged event when neutron detects some event in > the data plane (VIF plugging in OVS or some virtual switch). Thus I > think the question can be generalized to whether we expose a > capability (such that neutron server behaves in XXX way) through API > (API version? extension?). For example, do we have an extension to > expose that neutron supports the event callback mechanism? > > I also think the important point is that it is a topic of > deployment.Operators are responsible of deploying correct combination > of nova and neutron. > > Honestly I am not sure we need to expose this kind of things through > API. Regarding the current event callback mechanism, we assume that > operators deploy the expected combination of releases of nova and > neutron. Can't we assume that operators deploy Newton nova and neutron > when they want to use live-migration vif-plugging support? > > Akihiro > > 2016-06-06 17:06 GMT+09:00 Oleg Bondarev <obonda...@mirantis.com>: > > Hi, > > > > There are cases where it would be useful to know the version of Neutron (or > > any other project) from API, like during upgrades or in cross-project > > communication cases. > > For example in https://review.openstack.org/#/c/246910/ Nova needs to know > > if Neutron sends vif-plugged event during live migration. To ensure this it > > should be enough to know Neutron is "Newton" or higher. > > > > Not sure why it wasn't done before (or was it and I'm just blind?) so the > > question to the community is what are possible issues/downsides of exposing > > code version through the API? > > > > Thanks, > > Oleg > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
