QoS service plugin provides for now bandwidth limit rules for egress traffic
only (from VM point of view). QoS extension driver for Linuxbridge agent now
configures limits in proper way on tap interface so limited is traffic which is
outgoing from VM.
Linuxbridge agent's QoS extension configures egress bandwidth limit and burst
value in exactly same way how openvswitch is doing it with tc.
Old methods in TcCommand class will stay untouched because they can be used
later to implement also ingress bandwidth limits in QoS.
Change-Id: Id2b0463f49df52744e5bc3979a4cfd0ff06f9248
Closes-bug: #1563720
Add an rc hook that declaratively define what extensions
are going to be tested in the gate.
This has two benefits: a) it provides an easy switch to
disable intermittent/experimental APIs; b) it provides a
safeguard against accidental configuration errors that
may trigger the execution of dormant tests.
The 'service_type' extension has been skipped in preparation
of [1].
[1] https://review.openstack.org/#/c/195329/
Change-Id: I03e2394011aa747899b50e6eb64faca68866b388
Since adoption of the Tempest plugin framework, this
extra plumbing is no longer necessary in tree.
Related-bug: 1555356
Depends-on: If5f7ea82c45494953452f728fabb7403d0b6e14e
Change-Id: I5377f33c5a7b29f97f00878e048d154378a4fe34
I clicked on this link while reading the plugin development section in
the effective neutron guide. I wasn't sure it linked me to the right
thing because it currently links to a blank line. I figured that it
was just a line off but I wasn't sure because the link is to the
master branch, which can change.
This patch changes master to the short commit id of the commit that
added this link in the first place. This way, it'll always link to
what it originally linked to. If contents move around on master by
adding code to the file or refactoring or whatever, it might still
cause some confusion but at least we'll know what it was originally
intended to point to without doubt.
Change-Id: I13a10e10a31b88cb6f030ca644ca20e0bf14012c
Make use of the Tempest plugin interface instead of copying Neutron
files into Tempest. This will remove the burden to port Neutron
tests onto Tempest master recurrently.
It uses neutron/tests/tempest/ as new top folder for all Tempest
tests. It follows the model of Heat [1].
[1]: https://github.com/openstack/heat/tree/master/heat_integrationtests
Partially implements bp external-plugin-interface
Change-Id: Ia233aa162746845f6ae08a8157dcd242dcd58eab
This patch fixes typo "propogated" to correct word "propagated" in
Neutron plugin and Neutron managers Mechanism driver.
Change-Id: I837e2ad9d93d4b84b20ede764283dbf793bb3870
Let's skip the flaky tests until we find the root cause. The debugging
will happen with another patch that unblocks these tests so we still
have reproducer.
Change-Id: Icad4c1fb7a7ef9d6f5c34f48deb46ae286cb536b
Related-Bug: 1567668
The document is hopefully a good start and will eventually collect
enough information and tips for next release managers to run the
nervous process more smoothly.
Change-Id: Iaa14d818ae13e7cfa5ad061a2ae9d87a1f0fd331
Tempest commit ed6e586b9f8f0ada10af7711f297afa01b2b7754
changed configuration options defined in Tempest from
tenant to project. Currently we use Tempest from PyPI,
and since there hasn't yet been a Tempest release with
the change that breaks us, we're still safe, however the
next release will break us, so let's be ready for it.
Long term I think the correct thing to do would be to
define new options used exclusively in the Neutron tree.
Change-Id: I054b94a43d900e42872a9cb28d33a3ed45e14779
Neutron currently hardcodes the number of
greenlets used to process requests in a process to 1000.
As detailed in
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html
this can cause requests to wait within one process
for available database connection while other processes
remain available.
By adding a wsgi_default_pool_size option functionally
identical to that of Nova, we can lower the number of
greenlets per process to be more in line with a typical
max database connection pool size.
DocImpact: a previously unused configuration value
wsgi_default_pool_size is now used to affect
the number of greenlets used by the server. The
default number of greenlets also changes from 1000
to 100.
Change-Id: I94cd2f9262e0f330cf006b40bb3c0071086e5d71
This eases the deployment of a devstack machine with the latest
Open vSwitch bits, adding this to local.conf provides a fully
featured ovs-ct firewall setup:
enable_plugin neutron git://git.openstack.org/openstack/neutron
Q_BUILD_OVS_FROM_GIT=True
[[post-config|/$Q_PLUGIN_CONF_FILE]]
[securitygroup]
firewall_driver = openvswitch
Change-Id: Ia7ad1658b95d7404384c7cae833008a57e3e5af1
As compare_type in oslo_db already contains proper comparison for
Variant override in Neutron is not needed anymore.
Change-Id: Ifae67816ebb16372e6faca8f442f3153b171c1d9
resource_versions were included into agent state reports recently to
support rolling upgrades (commit 97a272a892fcf488949eeec4959156618caccae8)
The downside is that it brought additional processing when handling state
reports on server side: update of local resources versions cache and
more seriously rpc casts to all other servers to do the same.
All this led to a visible performance degradation at scale with hundreds
of agents constantly sending reports. Under load (rally test) agents
may start "blinking" which makes cluster very unstable.
In fact there is no need to send and update resource_versions in each state
report. I see two cases when it should be done:
1) agent was restarted (after it was upgraded);
2) agent revived - which means that server was not receiving or being able
to process state reports for some time (agent_down_time). During that
time agent might be upgraded and restarted.
So this patch makes agents include resource_versions info only on startup.
After agent revival server itself will update version_manager with
resource_versions taken from agent DB record - this is to avoid
version_manager being outdated.
Closes-Bug: #1567497
Change-Id: I47a9869801f4e8f8af2a656749166b6fb49bcd3b
The OFAgent driver and its agent are removed in the Newton cycle.
This adds to remove them in the release note.
Change-Id: I5dbcd38b0ccc156a6c1cbac4d7fa7f9d297ec466
Partial-Bug: #1521477