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
--
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
