<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-02 4:13 GMT+08:00 Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 8/1/2016 1:39 PM, Ken'ichi Ohmichi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2016-07-29 10:32 GMT-07:00 Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/28/2016 05:38 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 7/28/2016 3:55 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For os-attach-interfaces, we need that to attach/detach interfaces to a<br>
server, so those actions don't go away with 2.36. We can also list and<br>
show interfaces (ports) which is a proxy to neutron, but in this case it<br>
seems a tad bit necessary, else to list ports for a given server you<br>
have to know to list ports via neutron CLI and filter on<br>
device_id=server.uuid.<br>
</blockquote>
<br>
On second thought, we could drop the proxy APIs to list/show ports for a<br>
given server. python-openstackclient could have a convenience CLI for<br>
listing ports for a server. And the show in os-attach-interfaces takes a<br>
server id but it's not used, so it's basically pointless and should just<br>
be replaced with neutron.<br>
<br>
The question is, as these are proxies and the 2.36 microversion was for<br>
proxy API deprecation, can we still do those in 2.36 even though it's<br>
already merged? Or do they need to be 2.37? That seems like the more<br>
accurate thing to do, but then we really have some weird "which is the<br>
REAL proxy API microversion?" logic going on.<br>
<br>
I think we could move forward with deprecation in novaclient either way.<br>
</blockquote>
<br>
We should definitely move forward with novaclient CLI deprecations.<br>
<br>
We've said that microversions are idempotent, so fixing one in this case<br>
isn't really what we want to do, it should just be another bump, with<br>
things we apparently missed. I'm not sure it's super important that<br>
there is a REAL proxy API microversion. We got most of it in one go, and<br>
as long as we catch the stragglers in 2.39 (let's make that the last<br>
merged one before the release so that we can figure out anything else we<br>
missed, and keep get me a network as 2.37).<br>
</blockquote>
<br>
Yeah, I agree with another bump.<br>
We miss something like this and microversion mechanism can provide us<br>
with another chance.<br>
<br>
Thanks<br>
Ken Omichi<br>
<br>
---<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br></div></div>
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).<br>
<br>
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.</blockquote><div><br></div><div>A little strange we have two API endpoints, one is '/servers/{uuid}/os-interfaces', another one is '/servers/{uuid}/os-virtual-interfaces'.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>And sorry for I missed that when coding patches also...let me if you need any help at here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>