[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).
This can get pretty messy. I would be skeptical if we allowed this type of use case.