In an earlier change[1], a filter was added to avoid Linuxbridge races
with Nova. This filter breaks anything else using device owners other
than n(eutron|etwork):.
[1] https://review.openstack.org/#/c/193485/
Closes-Bug: #1524004
Closes-Bug: #1664659
Change-Id: I31a8e0e255b8b0251c991d5e20a4b9441d4ec489
When updating an ovsdb set-type column, the existing code does
the following:
1. Read the existing column value
2. Call verify() to cause a write failure if something else
modifies the column before we commit
3. Append the value to our local copy of the column
4. Assign the local value to the object.column to trigger
__setattr__ to write the value to the database
If verify() fails, which it *very* often does in a test
environment or a busy system, ovsdb-server will respond with a
TRY_AGAIN response which will cause the whole process to start
over.
In the 2.6 cycle, Row.addvalue()/delvalue() methods were added
which use OVDB's native 'mutate' methods to handle adding/deleting
from a set/map-type column. Using these means calling verify() is
no longer required and things will proceed *much* more efficiently.
Bug #1627106 where we get frequent TimeoutExceptions appears to be
related. Eliminating the frequent TRY_AGAIN responses, in my local
testing, also eliminates the TimeoutExceptions. This doesn't mean
that the underlying issue is resolved, but it may be avoided.
Related-Bug: #1627106
Change-Id: I26c7731f5dbd3bd2955dbfa18a7c41517da63e6e
Addresses TODO to prevent the same debug message from being
dumped to the logs repeatedly.
This is comparing string formats of dictionaries, which should
be safe since the pprint module sorts dictionaries by key first:
https://docs.python.org/2/library/pprint.html
TrivialFix
Change-Id: I6887d6e29840f7ac023e42f1a95cb586c6986b47
Patch I65da39fd390e4faecc6cfb18bb50e1f5ce684f1e changed the test to
start with port-security-enabled set to False and with no security
group. Later port security is turned on and security group is given but
immediatelly starts testing connectivity. It may happen that security
groups are not applied to the port yet and negative connectivity test
(former No. 3) fails. This patch actively waits for connection not to
pass and then continues as before.
Change-Id: Iddd66770638973a0b3c916f068b5c813886e07ef
Adding floating ips to floating_ips list in test_floating_ips
and test_revisions so they can be cleaned up when
resource_cleanup is called.
Change-Id: I80b50507a69b683dae0e003c5d881f14b8201976
Logging the ID of the callback should be enough
since the ID contains the path to the callback.
Before:
Notify callbacks
[('neutron.services.segments.db._update_segment_host_mapping_for_agent-8784700722903',
<function _update_segment_host_mapping_for_agent at 0x7fd58f74ed70>)]
for agent, after_create _notify_loop"
After:
Notify callbacks
['neutron.services.segments.db._update_segment_host_mapping_for_agent-8784700722903']
for agent, after_create _notify_loop"
TrivialFix
Change-Id: I01d886f2707479183d7ae9c530f5f3b7b3963340
This adds a helper that an L3 service provider can use to check
if a given router_id is associated with it. This makes skipping
events unrelated to the driver simple calls. See dependent patches
for examples.
Related: blueprint multi-l3-backends
Change-Id: I3ecb935722dd7fe75f73ad410225ff1b93b0f605
This may become handy when debugging gate failures like job or test case
or ovsdb timeouts, to see the load of the machine, as well as to
understand whether the machine was e.g. locked by its hypervisor during
test run.
Instead of using devstack as a library, we just enable the service in
local.conf [[localrc]], and then call ./stack.sh.
Now that we install some pypi packages into the system, and since
functional targets were using those system packages, post_gate_hook.sh
broke failing to locate subunit-2to1 script in the tox env directory. To
fix that, we disable sitepackages= for all functional tox targets. This
was enabled back in the times when we attempted to install neutron for
the functional job using devstack [1], and we no longer do it, so it
should be ok to stick to all packages from the tox venv.
[1] Icc38cacd69bc5843ccfcc60237a7102df6d8597f
Change-Id: I73857f63f512e26d595c61a20ec5bf22d2fb0da7
Basically, the commit removes the file encoding - since jenkins is fine
with it, means it was really unnecessary and the change makes sense.
Change-Id: Id0821c9b11b9efad1836596c407566c9eb4dc11a
It turns out that Neutron uses python-requests on just one place
and for no good reason. Given that loading Requests amount for 80MB
of RAM in my system, maybe it's worth removing our dependency on
requests.
Change-Id: I905252a55bd174ff1aa8bdec42fe32432746846f
This flag will force ebtables to acquire a lock so we don't
have to worry about ebtables errors occuring if something else
on the system is trying to use ebtables as well.
Closes-Bug: #1316621
Change-Id: I695c01e015fdc201df8f23d9b48f9d3678240266
This reverts commit 84b3ae3ae9111e241352bdccad238c9fd37b83df.
The logic was incorrect[1]. We cannot achieve QoS egress minimum bandwidth of Linuxbridge by the patch. I also think that the issue is not solved by small patch and we must consider deeply.
[1]: https://bugs.launchpad.net/neutron/+bug/1662582
Change-Id: Id4703b5c63876f16e31b6805cd147b5840a4a591
test.call_until_true has been deprecated since Newton on Tempest side,
and now Tempest provides test_utils.call_until_true as the stable
library method. So this patch switches to use the stable method before
removing old test.call_until_true on Tempest side.
Change-Id: I139b2ceeb9f840362ae4eeb06d391af4c83733ab
The devref describes tag mechanism supports network only but
now it supports subnet, port, subnetpool, and router.
This patch updates the description about supported resources.
Change-Id: I1a4b02e253157154218bfe63a18891083178f55a
Closes-Bug: #1662102
The initial implementation was measuring the bandwidth stability
over segments of time. But recent failures on high gate pressure
has shown that such stability can't be expected on the edge.
The test now checks the average bandwidth during the whole transmission.
Change-Id: Ic6a00f20ce76aba319ecdada79f68599c891cf29
Closes-Bug: #1662109
Security group rule setting remote_ip_prefix 0.0.0.0/0 for ipv4 or
::/0 for ipv6 plays the same role as the sg rules without setting
remote_ip_prefix. We could treat them as duplicate.
Change-Id: Ic9213e77d3b03aded7fc34d486066c8af4a3b2a1
Closes-Bug: #1534113