Load the Linux Driver Trunk agent extension driver only if the service
plugin is enabled. If the service plugin is not enabled, the agent
extension will not subscribe to the port events.
Change-Id: I883abb5ef122ac7f8fb029d0334fa2d68893f8aa
Closes-Bug: #1930443
The trunk constants now live in neutron-lib. This patch consumes them
by removing neutron.services.trunk.constants and using them from
neutron-lib instead.
Depends-On: https://review.opendev.org/#/c/650372/
NeutronLibImpact
Change-Id: I4445c44c7e321d0fc35976d4d855c148bb9a3b18
Commit 40866acd02 stopped passing agent
object as parameter as it's already referenced by `trigger' parameter.
This leads to an error during notify_after_init() in agents' code and
hence trunk handlers are never initialized. This patch replaces `agent'
reference with `trigger' to correctly initialize handlers.
Change-Id: I808980553056b9fec4e2700c1d5440e42091afbf
Closes-bug: #1722967
Since Pike log messages should not be translated.
This patch removes calls to i18n _LC, _LI, _LE, _LW from
logging logic throughout the code. Translators definition
from neutron._i18n is removed as well.
This patch also removes log translation verification from
ignore directive in tox.ini.
Change-Id: If9aa76fcf121c0e61a7c08088006c5873faee56e
This fixes the usage of the oslo RemoteError exception checking
in the Linux Bridge trunk driver to stop calling 'str' on the
exception and just check the 'exc_type' attribute like we do
in the other agent code so it's safe to use with unicode.
Change-Id: I352ed422550343118319f8e83c4979f290f161f0
Closes-Bug: #1697383
The callback modules have been available in neutron-lib since commit [1]
and are ready for consumption.
As the callback registry is implemented with a singleton manager
instance, sync complications can arise ensuring all consumers switch to
lib's implementation at the same time. Therefore this consumption has
been broken down:
1) Shim neutron's callbacks using lib's callback system and remove
existing neutron internals related to callbacks (devref, UTs, etc.).
2) Switch all neutron's callback imports over to neutron-lib's.
3) Have all sub-projects using callbacks move their imports over to use
neutron-lib's callbacks implementation.
4) Remove the callback shims in neutron-lib once sub-projects are moved
over to lib's callbacks.
5) Follow-on patches moving our existing uses of callbacks to the new
event payload model provided by neutron-lib.callback.events
This patch implements #2 from above, moving all neutron's callback
imports to use neutron-lib's callbacks.
There are also a few places in the UT code that still patch callbacks,
we can address those in step #4 which may need [2].
NeutronLibImpact
[1] fea8bb64ba7ff52632c2bd3e3298eaedf623ee4f
[2] I9966c90e3f90552b41ed84a68b19f3e540426432
Change-Id: I8dae56f0f5c009bdf3e8ebfa1b360756216ab886
Matching the MAC of the tap interface on the hypervisor
to the MAC that the VM will actually use to send traffic
through the tap causes the following error messages:
brq9e974900-cd: received packet on tapa8a6ce4a-e8 with
own address as source address
This is triggering a warning because there are now two
forwarding entries on the bridge, a static one from the
tap device, and a learned one from the packets received.[1]
Due to the presence of a static MAC entry, this will break
things like allowed_address_pair use cases that allow a MAC
to be used by multiple ports.
This patch removes all of the logic to set the MAC
address on the TAP device because it didn't serve any
other purpose than easy to correlate output from
ip link show commands and neutron port MAC addresses.
TAP devices will now just get whatever MAC address the kernel
selects for them.
1. https://lists.linuxfoundation.org/pipermail/bridge/2004-January/003740.html
Closes-Bug: #1668209
Change-Id: I0ff46f9550a79f486063a8e2810ed3b1140a4769
Maintaining the context is important for keeping the request ID
and subsequently operator/developer sanity while debugging.
The resource_type is also helpful to have since a function could be
subscribed for multiple resources.
This maintains and deprecates the existing 'subscribe' method for
backwards compatibility with callbacks that don't support receiving
the context and resource type. A new 'register' method is added
for callbacks to use that are compatible with receiving the context.
Change-Id: I06c8302951c99039b532acd9f2a68d5b989fdab5
The part of the linuxbridge trunk driver that actually triggered
the dataplane wiring for subport changes was incorrectly trying to
fetch the trunk using the trunk ID with a method expecting the port
ID. This would always result in it thinking the trunk wasn't on the
host and returning without wiring.
This fixes it by adding another method to fetch trunks by trunk ID.
All of the other operations in this function already expect trunk IDs.
This was discovered and the fix verified with the scenario test in
the dependent patch.
Change-Id: I25324bc1445cc083799ff54f8508a9505517ce84
Closes-Bug: #1625136
This is the agent-side implementation of vlan-aware-vms for
the Linux Bridge agent. It implements the feature using
vlan subinterfaces.
Whenever subports are required, the linux bridge trunk driver
will create vlan devices off of the parent port device following
the same naming scheme as normal ports. This allows the normal
agent loop to see these VLAN ports and wire them like any other
port so the trunk logic doesn't have to concern itself with things
like firewall rules, anti-spoofing, or encapsulation onto the
physical network.
How to try:
* enable the Linux Bridge mech driver and install the Linux Bridge agent
* enable the 'trunk' service plugin
* make a port, turn it into a trunk, attach it to a VM (or boot a VM with it)
* add subports and configure your guest on the corresponding VLAN
* don't forget these subports have security groups so add allow rules!
Partially-implements: blueprint vlan-aware-vms
Change-Id: I688d5b25885c1c3938185467b15502ccf65cf935