We pinned the python version to 3.9 because we had issues building
older meson 0.47.1 with python 3.10. Since then meson was updated to
0.53.2 in our CI, but we didn't reconsider the python version.
Newer versions of python uncover more issues with our python files.
And newer major distributions are using newer versions of python. But
we do not really want to use bleeding edge of python releases either to
avoid unexpected CI failures that need immediate fixes.
Pin python version to 3.12 as it is the latest released version and we
should not have any issues with this version.
While at it, updating meson to a newer version that plays nicely with
python 3.12. We do not really care much about the version we use here
as long as it is able to build the version of DPDK we're using. Meson
has no LTS releases, as far as I can tell, so just choosing the latest
stable 1.4.x series. It should be fine to use for a next few years.
Major distributions are using 1.0+ versions. Upcoming F40 and Ubuntu
24.03 have meson 1.3.
It would also be nice to test the minimal supported version of python,
but 3.6 is not available in setup-python for 22.04. The oldest is 3.7.
And 3.7 is EoL, so pip fails to install some of our dependencies. The
oldest version we can use today is 3.8. But, in the end, this becomes
a race against older python versions reaching end of their life and
packages dropping support of these versions. This may cause unexpected
CI failures. So, not doing that for now.
ovsdb-doc: Fix syntax warning with Python 3.12 and flake8 issues.
ovsdb-doc script generates the following syntax warning while running
with Python 3.12:
/ovsdb/ovsdb-doc:240: SyntaxWarning: invalid escape sequence '\{'
s += """
This doesn't cause a build failure because so far it's only a warning,
but it will become a syntax error in the future.
Fix that by converting to a raw string and removing unnecessary
escape sequences.
Adding ovsdb-doc to flake8-check to avoid re-introducing issues in
the future. This means also fixing all the other issues with the
script like unused imports and variables, long lines, missing empty
lines, wildcarded imports. Also cleaning up one place that handles
compatibility with Python 2 types, since we do not support Python 2
for a long time now.
ab21abf...
by
Dumitru Ceara <email address hidden>
python: Remove hacking dependency and use recent flake8.
The previously enabled 'hacking' checks were only applicable to Python 2
code. OVS doesn't support Python 2 for a while now so it's fine to
remove the dependency on hacking.
edfb2e0...
by
Frode Nordahl <email address hidden>
tests: Fix compatibility issue with Python 3.13 in vlog.at.
The vlog - Python3 test makes use of output from Python
Tracebacks in its test assertion.
In Python 3.13 a line with tophat (``^``) markers is added below
Tracebacks from calls to assert [0], which makes the test fail.
This change of behavior is also backported to the Python 3.12 and
3.11 stable branches [1].
Strip lines containing one or more occurrence of the ``^``
character from the output before performing the test assertions.
ofproto-dpif-upcall: Fix ukey installation failure logs and counters.
ukey_install() returns boolean signaling if the ukey was installed
or not. Installation may fail for a few reasons:
1. Conflicting ukey.
2. Mutex contention while trying to replace existing ukey.
3. The same ukey already exists and active.
Only the first case here signals an actual problem. Third one is
a little odd for userspace datapath, but harmless. Second is the
most common one that can easily happen during normal operation
since other threads like revalidators may be currently working on
this ukey preventing an immediate access.
Since only the first case is actually worth logging and it already
has its own log message, removing the 'upcall installation fails'
warning from the upcall_cb(). This should fix most of the random
failures of userspace system tests in CI.
While at it, also fixing coverage counters. Mutex contention was
mistakenly counted as a duplicate upcall. ukey contention for
revalidators was counted only in one of two places.
New counter added for the ukey contention on replace. We should
not re-use existing upcall_ukey_contention counter for this, since
it may lead to double counting.
0c263b6...
by
Paolo Valerio <email address hidden>
conntrack: Do not use icmp reverse helper for icmpv6.
In the flush tuple code path, while populating the conn_key,
reverse_icmp_type() gets called for both icmp and icmpv6 cases,
while, depending on the proto, its respective helper should be
called, instead.
The above leads to an abort:
[...]
__GI_abort () at abort.c:79
reverse_icmp_type (type=128 '\200') at lib/conntrack.c:1795
tuple_to_conn_key (...) at lib/conntrack.c:2590
in conntrack_flush_tuple (...) at lib/conntrack.c:2787
in dpif_netdev_ct_flush (...) at lib/dpif-netdev.c:9618
ct_dpif_flush_tuple (...) at lib/ct-dpif.c:331
ct_dpif_flush (...) at lib/ct-dpif.c:361
dpctl_flush_conntrack (...) at lib/dpctl.c:1797
[...]
Fix it by calling reverse_icmp6_type() when needed.
Furthermore, self tests have been modified in order to exercise and
check this behavior.
Fixes: 271e48a0e244 ("conntrack: Support conntrack flush by ct 5-tuple")
Reported-at: https://issues.redhat.com/browse/FDP-447
Signed-off-by: Paolo Valerio <email address hidden>
Signed-off-by: Ilya Maximets <email address hidden>
9de227d...
by
Paolo Valerio <email address hidden>
conntrack: Fix SNAT with exhaustion system test.
Recent kernels introduced a mechanism that allows to evict colliding
entries in a closing state whereas they were previously considered as
parts of a non-recoverable clash.
This new behavior makes "conntrack - SNAT with port range with
exhaustion test" fail, as it relies on the previous assumptions.
Fix it by creating and not advancing the first entry in SYN_SENT to
avoid early eviction.
ovsdb: raft: Fix inability to join after leadership change round trip.
Consider the following sequence of events:
1. Cluster with 2 nodes - A and B. A is a leader.
2. C connects to A and sends a join request.
3. A sends an append request to C. C is in CATCHUP phase for A.
4. A looses leadership to B. Sends join failure notification to C.
5. C sends append reply to A.
6. A discards append reply (not leader).
7. B looses leadership back to A.
8. C sends a new join request to A.
9. A replies with failure (already in progress).
10. GoTo step 8.
At this point A is waiting for an append reply that it already
discarded at step 6 and fails all the new attempts of C to join with
'already in progress' verdict. C stays forever in a joining state
and in a CATCHUP phase from A's perspective.
This is a similar case to a sudden disconnect from a leader fixed in
commit 999ba294fb4f ("ovsdb: raft: Fix inability to join the cluster
after interrupted attempt."), but since we're not disconnecting, the
servers are not getting destroyed.
Fix that by destroying all the servers that are not yet part of the
configuration after leadership is lost. This way, server C will be
able to simply re-start the joining process from scratch.
New failure test command is added in order to simulate leadership
change before we receive the append reply, so it gets discarded.
New cluster test is added to exercise this scenario.
Fixes: 1b1d2e6daa56 ("ovsdb: Introduce experimental support for clustered databases.")
Reported-at: https://github.com/ovn-org/ovn/issues/235
Acked-by: Han Zhou <email address hidden>
Signed-off-by: Ilya Maximets <email address hidden>
