2016-08-03 14:40 GMT+08:00 Alex Xu <sou...@gmail.com>:
>
>
> 2016-08-02 22:09 GMT+08:00 Matt Riedemann <mrie...@linux.vnet.ibm.com>:
>
>> On 8/2/2016 2:41 AM, Alex Xu wrote:
>>
>>> 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-requ...@lists.openstack.org?subject:unsubscribe
>>> <
>>> http://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
>>>
>>>
>> Alex,
>>
>> os-interface will be deprecated, that's the APIs to show/list ports for a
>> given server.
>>
>> os-virtual-interfaces is not the same, and was never a proxy for neutron
>> since before 2.32 we never stored anything in the virtual_interfaces table
>> in the nova database for neutron, but now we do because that's where we
>> store the VIF tags.
>>
>> We have to keep os-attach-interface (attach/detach interface actions on a
>> server).
>>
>> Are you suggesting we drop os-virtual-interfaces and change the behavior
>> of os-interfaces to use the nova virtual_interfaces table rather than
>> proxying to neutron?
>>
>
> Yes, but I missed the point your point out as below. The reason is that if
> we only deprecate the GET of os-interface, then when user want to add
> interface, user needs to send request 'POST /servers/{uuid}/os-interface'.
> When user want to query the interface which attach to the server, user
> needs send request to 'GET /servers/{uuid}/os-virtual-interfaces'. That
> means user access one resource but they are under different API endpoint.
>
> Initially I think we can use virtual_interface table to reimplement the
> GET of os-interface'. But as you pointed out, neutron ports won't show if
> it is created before Newton. That means we change the os-interface
> behaviour in old Microversion. Emm... I'm a little hesitate.
>
>
>>
>> Note that with os-virtual-interfaces even if we start showing VIFs for
>> neutron ports, any ports created before Newton won't be in there, which
>> might be a bit confusing.
>
>
> If we keep the os-virtual-interfaces, but we can't ensure this API works
> for all the instances forever. Due to we can't ensure there won't any old
> instance which created before Newton in user's cloud.
>
> So.. one idea, we keep the GET of os-interface, deprecate the
> os-virtual-interfaces in Newton. In Ocata, we use virtual_interface
> table/object instead of neutron API proxy, but we fallback to proxy neutron
> API when the instance haven't virtual_interface table( this is detected by
> compare the network_info_cache, instance have vif in network_info_cace, but
> no entry in virtual_interface table.).
>
And remove the code about fallback in the future, when we believe there
isn't any old instance.
>
>
>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __________________________________________________________________________
>> 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
