<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 April 2016 at 07:02, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 04/18/2016 04:48 PM, Matt Riedemann wrote:<br>
<snip><br>
<span class="">><br>
> I guess at a high level my thinking was always, if nova-network isn't<br>
> deprecated, and these APIs are broken when using Neutron, it's (mostly)<br>
> trivial to add a proxy to fill those gaps (like my spec for<br>
> os-virtual-interfaces). So then when people move from deprecated<br>
> nova-network to neutron, all of their tooling doesn't start breaking.<br>
><br>
> In thinking about it another way, if we just say nova-network is<br>
> deprecated again and therefore we have no incentive to make these APIs<br>
> work in the Neutron case, and want to force people off them, then I can<br>
> see that point.<br>
><br>
> It was different back in Havana when I was originally looking at this<br>
> because Neutron adoption was very different. With the recent survey,<br>
> however, it looks like nova-network is 7% of deployments now, and that's<br>
> including non-production. So I concede that it's making less sense to<br>
> put effort into making the APIs work with a proxy.<br>
<br>
</span>Right, I think in the Havana timeframe, things were very different. Part<br>
of the rationale for full parity was that applications would be written<br>
against nova-network, and smoothly transition to neutron. But with over<br>
90% neutron, assuming someone is writing to the nova-network API and not<br>
realizing it's the odd ball, I think is the wrong assumption. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The APIs that work, they are what they are, but we should not make any<br>
more work.<br></blockquote><div><br></div><div>Same may apply to security groups, but in a different context (e.g. when port-security was OFF). </div><div><br></div><div>There are a number of issues which we are all too aware of when interacting with nova's networking layer, whichever it may be. For example, when listing network-related commands available in the nova client there's a number of them that are documented to work with nova-net only (a) (e.g. floating-ip-bulk-create), and others that are left to the user to figure out (e.g. network-show) (b). Some are supposed to work for both, but there are gaps, like the one documented below (c).</div><div><br></div><div>Then, there are differences between nova-net and neutron when dealing with certain operations like nova boot (e.g. the issue that triggered get-me-a-network). That's class (d).</div><div><br></div><div>Of these classes, which ones do you intend to deprecate? Only (c)?</div><div><br></div><div>Thanks,</div><div>Armando</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="im"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class=""><div class="h5">__________________________________________________________________________<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>