Implement a hook point in Tricircle Cascading Neutron, in order to be able to customize the behavior of synchronizing all Cascaded instances with the creation of a new VM.
Context of new functionality
Currently in Tricircle, all Compute Nodes have a meshed overlay network, across the WAN.
After creating/moving a VM, the Cascading Neutron calls ML2Pop on each of the remaining Cascaded OpenStack instances to add the port mapping of the new VM.
With the addition of the BGW, the Compute Nodes are not meshed across the WAN anymore. Instead, the BGW is acting as the physical locator for a remote MAC.
In order to do that, we need to be able to implement a different behavior in Cascading Neutron, so that it can support the desired MAC learning behavior in the Cascaded layer (refer to #41 ).
The purpose of this task is to convert the hard-coded behavior into a plugin (including configuration), which can be replaced.
Overview of new functionality
Implement a hook point in Tricircle Cascading Neutron, in order to be able to customize the behavior of synchronizing all Cascaded instances with the creation of a new VM.
Context of new functionality
Currently in Tricircle, all Compute Nodes have a meshed overlay network, across the WAN. After creating/moving a VM, the Cascading Neutron calls ML2Pop on each of the remaining Cascaded OpenStack instances to add the port mapping of the new VM. With the addition of the BGW, the Compute Nodes are not meshed across the WAN anymore. Instead, the BGW is acting as the physical locator for a remote MAC. In order to do that, we need to be able to implement a different behavior in Cascading Neutron, so that it can support the desired MAC learning behavior in the Cascaded layer (refer to #41 ). The purpose of this task is to convert the hard-coded behavior into a plugin (including configuration), which can be replaced.