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.
Change-Id: I3ad8d6e7b8f103867ee277078d03f3a01c20ac0d
Closes-Bug: #1687709
Since 1b8664f8e1 moves qos
constants to neutron-lib, here we updates the link.
Also this patch adds short description for
supported QoS rule types.
Change-Id: Id6ebadc1dc9f6a4ea390f8c47dcdf72992494526
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.
NeutronLibImpact
Change-Id: I696b52265b9528082cd2524f05febe2338376488
This problem will cause self.host to be overridden by cfg.CONF.host
instead of the passed host value when calling MeteringAgent.__init__(host).
Change-Id: I50c5136e1cf1eb0db28edd02129f963948a54741
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.
Change-Id: Idbc1877e85a13faca150307b3e773c1ea5333b77
Closes-Bug: #1727132
As [1] 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.
[1] https://docs.openstack.org/security-guide/networking/architecture.html
Closes-Bug: #1720077
Change-Id: I14128aabe0a9209c31a1bd4c76eed1182364ccdf
Co-Authored-By: Slawek Kaplonski <slawek@kaplonski.pl>
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.
Closes-Bug: 1727988
Change-Id: I782e6d6fb6e575c00644f72602bc90a3d25bc18c
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.
NeutronLibImpact
Change-Id: I761381de0d6e26a0380386700e7921b824991669
neutron-lib contains the QoS constants. This patch removes them from
neutron and replaces all such uses to lib's QoS constants.
NeutronLibImpact
Change-Id: I6ed379b178a2b79fd14385a1d1e87d87eb04bfb9
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 [1] 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).
[1] http://codesearch.openstack.org/?q=from%20neutron.extensions%20import%20l3
Change-Id: Ifd79eb1a92853e49bd4ef028e7a7bd89811c6957
Tweak the wording so that it's a bit more clear on how to
handle rfe-approved RFEs and why certain RFEs are marked
as 'rfe-postponed'.
Change-Id: Iad66a1322918338ab51035de8fdb6b6ca23ddd8c
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.
Change-Id: I2586f0b11b107d7f57214a0d65bcf7c38a5f0ebb
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.
Change-Id: Icac99eb1d43648c64b6beaee0d6201f990eacb51
Related-bug: #1712185
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:
Iff56c9290d8e86cfc0e2bfa24176f8d1e338a06e
Change-Id: I78dee3b665185d7da9d854a23f1a7c9d6dbe96de
Closes-Bug: #1692134
Sławek Kapłoński