At the moment Neutron works out a binding_type it will tell Nova (which Nova must support or else). Nova is amazingly psychic, and knows that for many binding types, some specific widget will be created with a certain specific name. This runs into problems because firstly they must be configured the same and secondly drivers (ODL in particular is one of interest) may support multiple or unpredictable binding_types.
Additionally, Nova's code has code in it for each binding type to predict what the binding will be (e.g. bridge or TAP names).
I suggest two things:
- we should get Nova to tell us what binding types it supports so that we can choose one of those
- to simplify the Nova code, and eventually remove the complexity of its synchronised guesswork - we do as much work as possible in Neutron, and we ensure that we pass all this information over in binding_details.
I'm trying to get a spec approved for Nova that would make it tell us what binding types are available. The other half is also under some discussion.
In some cases this can lead to something that might be considered a security issue, or at least a bit dangerous, like Neutron telling Nova it should do something stupid with eth0, or create a new socket at /etc/passwd. We may want to put a few restrictions that both Nova and Neutron respect, like device prefixes or file locations, for safety's sake.
I propose that we don't change the binding code that exists, so that the next version of Nova remains compatible with the current version of Neutron, but we do create new binding types that use explicit exchange instead of spooky action at a distance. If Neutron is given a preference list of types, it will use the most preferred one, and Nova can offer the new types in preference to the old ones. In the future, we can deprecate and remove the old binding types.
seems we need to refactor this RFE according to https:/