Open Stack

2016-08-02 4:13 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:

> On 8/1/2016 1:39 PM, Ken'ichi Ohmichi wrote:
>
>> 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.
>>
>> Thanks
>> 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
>>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
> OK I'll take a stab at writing a spec for this either tonight or tomorrow.
> We'll deprecate the proxy APIs for os-attach-interfaces show and list
> methods. We'll need to take into account that the create (attach interface)
> action uses the show method which proxies to neutron's show_port method,
> but I think we will have enough information to avoid that proxy (that could
> probably just be a separate bug fix actually).
>
> As for os-virtual-interfaces, I don't plan on deprecating that, and
> actually plan on enhancing it with a microversion in Ocata to return the
> vif tags from the model (useful for microversion 2.32). Plus we'll be able
> to use that for both nova-net and neutron since the data isn't proxied from
> anywhere, it just comes from the nova DB.


A little strange we have two API endpoints, one is
'/servers/{uuid}/os-interfaces', another one is
'/servers/{uuid}/os-virtual-interfaces'.

I prefer to keep os-attach-interface. Due to I think we should deprecate
the nova-network also. Actually we deprecate all the nova-network related
API in the 2.36 also. And os-attach-interface didn't support nova-network,
then it is the right choice.

So we can deprecate the os-virtual-interface in newton. And in Ocata, we
correct the implementation to get the vif info and tag. os-attach-interface
actually accept the server_id, and there is check ensure the port belong to
the server. So it shouldn't very hard to get the vif info and tag.

And sorry for I missed that when coding patches also...let me if you need
any help at here.


>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160802/d1dd6e40/attachment.html>