yahoo-eng-team team mailing list archive

[Jason Niesz <mainx07@xxxxxxxxx>]

Public bug reported:

[Description]
Currently it is not possible to run multiple L2 agents on a host without them conflicting with each other.  For example, if I set up and configure Linux bridge and Open vSwitch agents on a compute host both agents will try to enslave the tap interface of the instance resulting in a conflict.  

[Proposed Change]
Add a mechanism to associate a network to an L2 agent type.  When a new network is provisioned it would get associated with an L2 agent type.  When a new instance is launched on that network only the appropriate L2 agent would get called to enslave the tap interface of the instance.  

[Reason for Change]
Having the capability to run multiple L2 agents on a host and associating networks to an agent type would allow for in place migrations between different networking scenarios.  An example of this would be migrating from provider networking with Linux bridge to DVR with OVS.  With this new capability, I could configure and spin up OVS agents across all my compute hosts and provision new networks associated with the OVS agent type.  I could then migrate instances over from provider networking to DVR with OVS.  The current option for migration forces me to have a separate set of dedicated compute hosts for migrating between different networking scenarios.

There could also be other reasons to support multiple L2 agents, such as
performance or functionality.  It might make sense to back one network
with OVS and another with Linux bridge.  While I gave Linux bridge and
OVS as examples, the number of L2 agents could also include possible
future options, such as Cisco Vector Packet Processing (VPP).

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1544676

Title:
  [RFE] Support for multiple L2 agents on a host

Status in neutron:
  New

Bug description:
  [Description]
  Currently it is not possible to run multiple L2 agents on a host without them conflicting with each other.  For example, if I set up and configure Linux bridge and Open vSwitch agents on a compute host both agents will try to enslave the tap interface of the instance resulting in a conflict.  

  [Proposed Change]
  Add a mechanism to associate a network to an L2 agent type.  When a new network is provisioned it would get associated with an L2 agent type.  When a new instance is launched on that network only the appropriate L2 agent would get called to enslave the tap interface of the instance.  

  [Reason for Change]
  Having the capability to run multiple L2 agents on a host and associating networks to an agent type would allow for in place migrations between different networking scenarios.  An example of this would be migrating from provider networking with Linux bridge to DVR with OVS.  With this new capability, I could configure and spin up OVS agents across all my compute hosts and provision new networks associated with the OVS agent type.  I could then migrate instances over from provider networking to DVR with OVS.  The current option for migration forces me to have a separate set of dedicated compute hosts for migrating between different networking scenarios.

  There could also be other reasons to support multiple L2 agents, such
  as performance or functionality.  It might make sense to back one
  network with OVS and another with Linux bridge.  While I gave Linux
  bridge and OVS as examples, the number of L2 agents could also include
  possible future options, such as Cisco Vector Packet Processing (VPP).

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