Public bug reported:
I'm trying to get a spec approved for Nova that would make it tell us
what binding types are available. This would seem like a golden
opportunity to clean the interface up.
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. I suggest that - 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.
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.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1464465
Title:
RFE: binding_type improvements
Status in OpenStack Neutron (virtual network service):
New
Bug description:
I'm trying to get a spec approved for Nova that would make it tell us
what binding types are available. This would seem like a golden
opportunity to clean the interface up.
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. I suggest that - 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.
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1464465/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
