Trunk driver is not needed to be initialized when "trunk"
service plugin is not enabled.
On production environments it's not possible to base on
"service_plugins" config option on L2 agent's side so this
driver is initialized always.
It cause problems on fullstack tests becasue there is race
condition between different ovs agents which consumes events
from Openvswitch monitor.
On fullstack tests however we can assume that agent's and server's
config are in sync so trunk driver can be initialized only if
"trunk" service plugin is enabled on server side.
The external network extension's API definition was rehomed into
neutron-lib with I9933b91d1e82db3891b3b72f06e94316e56a4f15. This patch
consumes it, switch over to neutron-lib's modules and removing the
rehomed code in neutron.
The example of "detach a port from the QoS policy" is
wrong in config qos doc.
OpenStack client don't display info about "Updated" after
set or unset operation. Egg, associate the created policy
with an existing neutron port, or detach a port from the
QoS policy. It is the same as network.
Also, OpenStack client don't display info about "Updated
or Deleted" when we modify or delete rules from Qos policy.
As  shows, the controller node hosts the Neutron server but
also agents like L3 and DHCP which require also OVS or LinuxBridge
agent to be running on it.
To enable QoS is required to enable the 'service_plugins' and
the 'extension_drivers', along with the agent section in the plugin
config if the agent is running on this host.
In the network node and the compute node only the agent
'extensions' configuration is needed to enable QoS
on the agent.
Co-Authored-By: Slawek Kaplonski <firstname.lastname@example.org>
Commit I2586f0b11b107d7f57214a0d65bcf7c38a5f0ebb changed the private
_setUpExtension() method in neutron/tests/unit/extensions/base.py by
removing a now unused parameter. However consumers are using the private
method so the resulting change breaks them in some cases.
This patch adds the param back as well as a todo to phase it out by
moving consumers off it 1st.
Commit I1d4ded9959c05c65b04b118b1c31b8e6db652e67 rehomed the
availability zone extension's API definition into neutron-lib. This
patch consumes it, removing the rehomed logic in neutron and switching
over to lib's version of it.
Commit I81748aa0e48b1275df3e1ea41b1d36a117d0097d added the l3 extension
API definition to neutron-lib and commit
I2324a3a02789c798248cab41c278a2d9981d24be rehomed the l3 exceptions.
While we'd like to just consume the changes in neutron, many consumers
use the l3 extension  and have branching code that depends on
checking the l3 exceptions. Therefore we can't switch consumers over
using a one-step approach as they will be branching off lib exceptions
while neutron is raising it's own exceptions.
This patch shims the neutron l3 exceptions to ref neutron-lib's. This
will allow us to move consumers over to the l3 code in lib and then
finally consume the l3 changes in lib (removing the shims as well).
Today our unit test code uses various ways to "patch" the global
RESOURCE_ATTRIBUTE_MAP as well as extension specific maps in some cases.
This patch consolidates such patching whereby tests should use neutron's
AttributeMapMemento in their setup() chain (only once) if they update
the global map and they should individually handle backup/restore of per
extension map updates. This change will simplify the code and make it
easier to phase-in API definition usage with neutron-lib where we have
some as API definitions and others not. Longer term the
AttributeMapMemento will be replace with neutron-lib's fixture as we
move all extension maps to API definitions in neutron-lib.
In the case where we called iptables-restore with a
-w argument and it succeeded, we should short-circuit
future calls to always use -w, instead of trying
without it, just to fall-back to using it on failure.
While analyzing some l3-agent log files I have seen
lots of "Perhaps you want to use the -w option?",
followed by a call with -w, followed by not using it
the next time. Changing this can save one failing
call to iptables-restore.
The following operations are enforced by this change:
* all v4 names/ints can be created in both v4 and v6 networks
* all v6 names/ints can be created in v6 networks
* no v6 names/ints can be created in v4 networks
This patch is a follow up to the doc chage: