On Mon, Jun 6, 2016 at 2:03 PM, Armando M. <arma...@gmail.com> wrote:
> > > On 6 June 2016 at 10:06, Oleg Bondarev <obonda...@mirantis.com> wrote: > >> 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? >> > > If you are not talking about features exposed through the API (for which > they'd have a new extension being advertised), knowing that you're running > a specific version of the code might not guarantee that a particular > feature is available, especially in the case where the capability is an > implementation detail that is config tunable (evil, evil). This may also > lead to needless coupling between the two projects, as you'd still want to > code defensively and assume the specific behavior may or may not be there. > Agree, that's why we have extensions-list in the API, right? > > I suspect that your case is slightly different in that the lack of a > received event may be due to an error rather than a missing capability and > you would not be able to distinguish the difference if not optimistically > assume lack of capability. Then you need to make a "mental" note and come > back to the code to assume a failure two cycles down the road from when > your code merges. Definitely not a pretty workflow without advertising the > new feature explicitly via the API. > I'd not call it a feature, but a tiny behavior change for the neutron reference implementation: if patch https://review.openstack.org/#/c/246898/ merges in Newton then we can be sure that neutron (newton or higher) with ml2+ovs should send a particular event to nova during live migration (if it doesn't than it a bug, but it's another topic) and nova can be sure it should wait for this event. > > >> >> 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