Open Stack

On 19 April 2016 at 07:02, Sean Dague <sean at dague.net> wrote:

> On 04/18/2016 04:48 PM, Matt Riedemann wrote:
> <snip>
> >
> > I guess at a high level my thinking was always, if nova-network isn't
> > deprecated, and these APIs are broken when using Neutron, it's (mostly)
> > trivial to add a proxy to fill those gaps (like my spec for
> > os-virtual-interfaces). So then when people move from deprecated
> > nova-network to neutron, all of their tooling doesn't start breaking.
> >
> > In thinking about it another way, if we just say nova-network is
> > deprecated again and therefore we have no incentive to make these APIs
> > work in the Neutron case, and want to force people off them, then I can
> > see that point.
> >
> > It was different back in Havana when I was originally looking at this
> > because Neutron adoption was very different. With the recent survey,
> > however, it looks like nova-network is 7% of deployments now, and that's
> > including non-production. So I concede that it's making less sense to
> > put effort into making the APIs work with a proxy.
>
> Right, I think in the Havana timeframe, things were very different. Part
> of the rationale for full parity was that applications would be written
> against nova-network, and smoothly transition to neutron. But with over
> 90% neutron, assuming someone is writing to the nova-network API and not
> realizing it's the odd ball, I think is the wrong assumption.
>
The APIs that work, they are what they are, but we should not make any
> more work.
>

Same may apply to security groups, but in a different context (e.g. when
port-security was OFF).

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).

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).

Of these classes, which ones do you intend to deprecate? Only (c)?

Thanks,
Armando


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20160419/474eac1a/attachment.html>