yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1464465@xxxxxxxxxxxxxxxxxx>]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

-- 
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:
  binding_type improvements to simplify Nova interactions

Status in neutron:
  Expired

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1464465/+subscriptions