2016-08-02 4:13 GMT+08:00 Matt Riedemann <mrie...@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 <s...@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-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 >> >> > 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-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
