[openstack-dev] [nova] os-virtual-interfaces isn't deprecated in 2.36

Ken'ichi Ohmichi ken1ohmichi at gmail.com
Mon Aug 1 18:39:21 UTC 2016

2016-07-29 10:32 GMT-07:00 Sean Dague <sean at dague.net>:
> On 07/28/2016 05:38 PM, Matt Riedemann wrote:
>> On 7/28/2016 3:55 PM, Matt Riedemann wrote:
>>> For os-attach-interfaces, we need that to attach/detach interfaces to a
>>> server, so those actions don't go away with 2.36. We can also list and
>>> show interfaces (ports) which is a proxy to neutron, but in this case it
>>> seems a tad bit necessary, else to list ports for a given server you
>>> have to know to list ports via neutron CLI and filter on
>>> device_id=server.uuid.
>> On second thought, we could drop the proxy APIs to list/show ports for a
>> given server. python-openstackclient could have a convenience CLI for
>> listing ports for a server. And the show in os-attach-interfaces takes a
>> server id but it's not used, so it's basically pointless and should just
>> be replaced with neutron.
>> The question is, as these are proxies and the 2.36 microversion was for
>> proxy API deprecation, can we still do those in 2.36 even though it's
>> already merged? Or do they need to be 2.37? That seems like the more
>> accurate thing to do, but then we really have some weird "which is the
>> REAL proxy API microversion?" logic going on.
>> I think we could move forward with deprecation in novaclient either way.
> We should definitely move forward with novaclient CLI deprecations.
> We've said that microversions are idempotent, so fixing one in this case
> isn't really what we want to do, it should just be another bump, with
> things we apparently missed. I'm not sure it's super important that
> there is a REAL proxy API microversion. We got most of it in one go, and
> as long as we catch the stragglers in 2.39 (let's make that the last
> merged one before the release so that we can figure out anything else we
> missed, and keep get me a network as 2.37).

Yeah, I agree with another bump.
We miss something like this and microversion mechanism can provide us
with another chance.

Ken Omichi


> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list