On 4/19/2016 5:56 PM, Armando M. wrote:
On 19 April 2016 at 07:02, Sean Dague <[email protected] <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe <http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
