Functional tests log to a file only if they inherit from
the Sudo tests base class. This patch changes the base
class for some test cases to make them log.
Turns out the patch with Git commit hash prefix 13993764
disabled functional tests logging completely. This patch
fixes that by moving the neutron-db-manage logging setup
from import to the main function. Fixing that, it looks like
patch with Git commit hash prefix 4980f031fe turned off
DEBUG level logging for functional tests. I changed the
tests default logging from INFO to DEBUG to fix that.
Forking a process when multiple threads are running is an unsafe
operation and could cause a lot of problems because only current
thread will continue working in child thread. Any locked by other
thread resource will remain locked forever.
We faced with this problem during oslo.messaging development and
added workaround to hide this problem:
I tried to fix this problem in oslo.service:
but oslo folks said that this fix is ugly and it is wrong way to add
workarounds to common libraries because projects use them incorrectly.
I think that is fair.
So this patch fixes incorrect usage of oslo libraries. In this patch
I extended functionality of NeutronWorker and add there
`worker_process_count` parameter which determines how many processes
should be spawned for this worker. If `worker_process_count` = 0 - don't
create process and spawn thread in scope of current process for worker
Then I moved all background tasks to workers and return them by
`get_workers` method. start_plugin_workers collects plugin's workers
using `get_workers` method and starts in ProcessLauncher first workers
with `worker_process_count` > 0 and only after this starts threaded
workers by simple Launcher
Currently fullstack tests don't use hybrid plugging but they use hybrid
firewall by default. Using iptables is not segregated and OVS agents
running in parallel may interfere between each other.
This patch removes using iptables in ovs agents per created port.
This was planned to be removed a long time ago but no one ever got to
it. This shouldn't come as a surprise.
Co-authored-by: Ryan Moats <email@example.com>
The paginate_query method was copied from nova which was copied
from glance. Now it is available in oslo_db.
Check and convert the sort keys and sort directions for
consumption by the oslo_db version of the method, and fix up
some grammar in the exception messages.
This work is related to the neutron-lib effort. The lib should
not propagate neutron's copy of paginate_query().
IPv6 includes the concept of link-local addresses. There are address
within the fe80::/64 prefix which are used only within the local layer 2
network. They should never be routed. DHCPv6 is one of several protocols
which utilize link-local addresses.
Previously the blanket permit DHCPv6 rule permitted DHCPv6 requests from
a link-local source, before the source address was validated.
The structure of the IPtables egress firewall is:
a. fixed rules for special traffic
b. validate source address
c. fixed rules necessary for host to function
d. user rules defined by security groups
This change restricts the special traffic permitted in part (a) to only
that traffic which utilizes the "unspecified address" (::), by moving
the fixed permit ICMPv6 and DHCPv6 rules to part (c), so they are
applied after the source address has been validated. In order to enable
DHCPv6 and other protocols utilizing link-local addresses, the
link-local address corresponding to each MAC address are included in the
permitted source addresses. After the source address is verified, the
fixed rules permit ICMPv6 and DHCPv6, then the user defined security
group rules are applied.
In the existing implementation ICMPv6 and DHCPv6 rules in the fixed
ip6tables firewall rules are too permissive: they permit ICMPv6 and
DHCPv6 traffic, regardless of source MAC or IPv6 address. These rules
where intended to allow a host to acquire an IPv6 address, but
inadvertently allowed a malicious or compromised host to spoof another's
MAC or IPv6 address.
A host acquiring an IPv6 address should preform DAD (duplicate address
detection). To preform this the host must join the multicast group
corresponding to the tentative IPv6 address and the all nodes multicast
group. To join these groups the host sends ICMP MLD (multicast listener
discovery) report messages before it has an IPv6 address assigned, so
the unspecified address is used as the source address. To complete DAD,
ICMP neighbor solicitation messages are sent to solicit if any nodes
using that address. This should be the only use of the unspecified IPv6
address as a source address. The IPv4 case is similar the unspecified
address is used for DHCP discovery and request messages.
To summarize, this patch permits only ICMPv6 traffic from the unspecified
address which is used for duplicate address detection. Then it enforces
the source IPv6 and MAC addresses and finally, allows only ICMPv6 traffic
which has passed this source address validation.
In addition this patch permits traffic from all link-local addresses
associated with each MAC address assigned to the port. This is required
by many IPv6 protocols, such as DHCPv6, which depend on the link-local
addresses. This traffic was previously allowed by the blanket allow
ICMPv6 and allow DHCPv6 rules before the source address was validated.
Finally, it includes a functional test for IPv6 spoofing using both
ICMPv6 and DHCPv6 traffic. OVSFirewall currently permits this spoofed
DHCPv6 traffic. I'm excluding the OVSFirewall implementation from test
so it can be fixed in a follow on patch.
Once the spinout is undergoing we should perform the eviction.
Partially-implements: blueprint bgp-spinout
Some 'Port' queries use 'device_id' column for lookup.
Such queries could be observed in database query log (at least) during
instance launch. In the absence of 'device_id' index that leads to full
table scan. That causes unnecessary database load and impacts query
This reverts commit 81823e8632.
Unneeded optimization: this commit only improves execution
time on the order of milliseconds, which is less than 1% of
the total router update execution time at the network node.
This patch introduces the following:
- data models and related schema migrations
- first stub at DB operations
- trunk module structure
This is a tepid attempt to land the first functional code
for this sorely needed feature.
Partially-implements: blueprint vlan-aware-vms
Without setattr defined, setting an attr will end up
setting a new attribute on the deprecated instance
rather than changing my_globals. This means that other
functions in my_globals that have a reference to the original
will have a different view than external users that get
the new attribute.
This test has run out of its useful purpose. It was meant to protect
accidental schema changes involving external tables. After a few cycles
now, it is very unlikely that human error will not be spotted during
code review, where external tables are referenced/modified during Neutron
core schema migrations.
Putting effort into fixing the BGP removal corner case is not worth it,
and it is probably best to get rid of the test entirely.
Current OVSDB Connection will register all tables with schema_helper.
It doesn't matter for most cases, but for implementation for bp
routed-networks in networking-ovn, we don't need all tables in OVN_
Southbound DB are registered. We only need a certain table named
Chassis can be registered.
This patch add a parameter for OVSDB Connection to allow it to
register certain tables, instead of all tables.
This reverts commit 7a4633a9ca.
Revert to using 0 as the default value for path_mtu.
In most situations, underlying MTU does not differ for tunnel backed and
vlan/flat tenant networks, in which case the only configuration expected
from operators is setting global_physnet_mtu to the appropriate MTU
value as reflecting all data paths that tenant traffic may take between
But with the non-zero value set for path_mtu, if an operator would like
to raise the global underlying MTU used by neutron to support Jumbo
frames, both global_physnet_mtu and path_mtu need a bump, which is not
So switch back to using a zero value for path_mtu, effectively making it
not participating in MTU calculation, unless explicitly overridden.
Left the original release note intact since it reflects the state for
Added a release note for the change.