yahoo-eng-team team mailing list archive

[Ian Wells <iawells@xxxxxxxxx>]

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