Open Stack

On 4/19/2016 5:56 PM, Armando M. wrote:
>
>
> On 19 April 2016 at 07:02, Sean Dague <sean at dague.net
> <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

(c) in my opinion, and eventually probably (a) for the nova-network only 
APIs iff nova-network is officially deprecated again at some point, 
which I think we plan on doing.

-- 

Thanks,

Matt Riedemann