[openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
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?
The nova compute API understands how the nova-network API and neutron
APIs work. nova-network is deprecated , and we're deprecating the API
proxies for network resources out of the nova API . We're also
dropping API extensibility . 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
 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.
More information about the OpenStack-dev