[openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Jun 30 20:12:25 UTC 2016

On 6/30/2016 12:55 PM, HU, BIN wrote:
> I see, and thank you very much Dan. Also thank you Markus for unreleased release notes.
> Now I understand that it is not a plugin and unstable interface. And there is a new "use_neutron" option for configuring Nova to use Neutron as its network backend.
> When we use Neutron, there are ML2 and ML3 plugins so that we can choose to use different backend providers to actually perform those network functions. For example, integration with ODL.
> Shall we foresee a situation, where user can choose another network backend directly, e.g. ODL, ONOS? Under this circumstance, a stable plugin interface seems needed which can provide end users with more options and flexibility in deployment.
> What do you think?
> Thanks
> Bin

The nova compute API understands how the nova-network API and neutron 
APIs work. nova-network is deprecated [1], and we're deprecating the API 
proxies for network resources out of the nova API [2]. We're also 
dropping API extensibility [3]. Having plugin implementations for the 
networking (or image, or volume, or identity) API can break Nova's API 
which breaks users.

For anyone following along with nova development for the last several 
releases this shouldn't be a surprise. Plug points, hooks, and API 
extensions that can modify API requests/responses/resources are barriers 
to interoperability between OpenStack clouds. There is a big long thread 
[4] that goes into more details about why.

But these also present issues for nova development upstream because 
people report bugs when we break these unversioned, untested, 
non-contractual interfaces which downstream people are plugging into.

So if there is a use case that nova (or neutron) does not today support, 
we encourage people to not work in a vacuum but get involved with the 
development effort in the community, attend the summit design sessions, 
attend the meetups, be in IRC and the development mailing list, etc so 
that these things can be worked together in the open.

[1] https://review.openstack.org/#/c/310539/
[4] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097349.html



Matt Riedemann

More information about the OpenStack-dev mailing list