Before the patch, the size of the backlog depended on the type of socket
(UNIX vs INET) as well as on the language (C vs Python), specifically:
- python used backlog size = 10 for all sockets;
- C used 64 for UNIX sockets but 10 for INET sockets.
This consolidates the values across the board. It
Remove the notion of cluster/leave --force since it was never
implemented. Instead of these instructions, document how a broken
cluster can be re-initialized with the old database contents.
Signed-off-by: Ihar Hrachyshka
---
Documentation/ref/ovsdb.7.rst | 50 +--
It's always NULL.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 6a8ace52f..78028131f 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -4336,7 +4336,7 @@
It's always NULL.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 78028131f..6a51e5bad 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -4358,7 +4358,6 @@
The original version of the scenario passed with or without the fix.
This is because all LSs were processed in one go, so the allocate
function was never entered with *hint==0.
Also, added another scenario that will check behavior when *hint is out
of [min;max] bounds but > max (this happens in
This allows callers to avoid cleanup of the record in case the function
fails.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 4cea669cf..6a8ace52f 100644
---
In some scenarios, op->list is not attached anywhere, which makes
attempts to detach it trigger ubsan failure.
ovn/ovs/include/openvswitch/list.h:252:17: runtime error: member access
within null pointer of type 'struct ovs_list'
#0 0x?? in ovs_list_remove
Let the callers do the cleanup as needed.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 02cf5b234..f2406890c 100644
--- a/northd/northd.c
+++
v2+ of the original test patch exposed a ubsan failure in port tunnel id
allocation code when tunnel id space is exhausted.
This series fixes the ubsan failure (patches 1-2); then adjusts the
invalid scenario to trigger the originally intended failure mode - id
space exhausted (patch 3). Finally,
Inactivity probe interval on RAFT connections depend on a value of the
election timer. However, the actual value is not known until the
database snapshot with the RAFT information is received by a joining
server. New joining server is using a default 1 second until then.
In case a new joining
If the new snapshot received with INSTALL_SNAPSHOT request contains
a different election timer value, the timer is updated, but the
probe intervals for RAFT connections are not.
Fix that by updating probe intervals whenever we get election timer
from the log.
Fixes: 14b2b0aad7ae ("raft:
A couple of fixes related to corner cases with probe intervals
on RAFT connections between servers.
Ilya Maximets (2):
ovsdb: raft: Fix inability to join a cluster with a large database.
ovsdb: raft: Fix probe intervals after install snapshot request.
ovsdb/raft.c | 23
Current regexp is not good enough. OpenSSL 3.3.0 is now available
and unfortunately the regexp is matching both 3.3.0 and 3.0.13.
All the AppVeyor runs are currently failing because of this.
Making it more restrictive by matching on the start of the string,
explicit dots and numbers after the
Sorry, this is incorrect, the order of steps here is important. Instead, we
should clean up the newly created record on failure. (Other patches in the
series are ok; will send an updated series.)
On Thu, Apr 11, 2024 at 6:59 PM Ihar Hrachyshka wrote:
> This allows to avoid cleanup of the record
Series with this patch that also fixes ubsan failure here:
https://patchwork.ozlabs.org/project/ovn/list/?series=402694
On Mon, Apr 8, 2024 at 9:49 AM Ihar Hrachyshka wrote:
> Note to reviewers: looks like the port tunnel id test case revealed a
> number of undefined behaviors and leaks (?) in
It's always NULL.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index adc8930c8..044a69264 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -4353,7 +4353,6 @@
Let the caller do the cleanup, as needed.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index f2406890c..ace663d54 100644
--- a/northd/northd.c
+++
The `op` here is a new port structure that is not, yet, attached
anywhere, and the attempt to detach it will result in undefined
behavior.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/northd/northd.c b/northd/northd.c
index
The original version of the scenario passed with or without the fix.
This is because all LSs were processed in one go, so the allocate
function was never entered with *hint==0.
Also, added another scenario that will check behavior when *hint is out
of [min;max] bounds but > max (this happens in
It's always NULL.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 5a0225189..adc8930c8 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -4331,7 +4331,7 @@
This allows to avoid cleanup of the record in case tunnel id fails to
allocate.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 3d2715911..5a0225189 100644
---
v2+ of the original test patch exposed a ubsan failure in port tunnel id
allocation code when tunnel id space is exhausted.
This series fixes the ubsan failure (patches 1-3); then adjusts the
invalid scenario to trigger the originally intended failure mode - id
space exhausted (patch 4). Finally,
Let the callers do the cleanup as needed.
Signed-off-by: Ihar Hrachyshka
---
northd/northd.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 02cf5b234..f2406890c 100644
--- a/northd/northd.c
+++
On 4/11/24 00:43, Ilya Maximets wrote:
> Fixing a few more issues with Python 3.12 and Python files in general.
> Switch CI testing to Python 3.12, more explanation in commit messages.
>
> Plan s to also backport these changes to fix issues on older branches
> and also to have uniform CI on all
On 11/04/2024 17:10, Dumitru Ceara wrote:
On 4/11/24 15:43, Chris Riches wrote:
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
Hi Chris, Ilya,
From what we know so far, the DB was full of stale connection-tracking
information such as the following:
[...]
On 4/11/24 15:43, Chris Riches wrote:
> On 11/04/2024 14:24, Ilya Maximets wrote:
>> On 4/11/24 10:59, Chris Riches wrote:
Hi Chris, Ilya,
>>> From what we know so far, the DB was full of stale connection-tracking
>>> information such as the following:
>>>
>>> [...]
>>>
>>> Once the host was
I tried to build OVN in a fresh Ubuntu 24.04 Docker container.
I only installed the Build-Depends.
I ran:
$ dpkg-buildpackage -us -uc -ui -b
And I received the following output:
dpkg-buildpackage: info: source package ovn
dpkg-buildpackage: info: source version 24.03.90-1
dpkg-buildpackage:
Bleep bloop. Greetings Jakob Meng, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
From: Jakob Meng
The 'list-commands' command now supports machine-readable JSON output
in addition to the plain-text output for humans.
Reported-at: https://bugzilla.redhat.com/1824861
Signed-off-by: Jakob Meng
---
NEWS | 1 +
lib/unixctl.c | 46
From: Jakob Meng
The 'dpif/show' command now supports machine-readable JSON output in
addition to the plain-text output for humans. An example would be:
ovs-appctl --format json dpif/show
Reported-at: https://bugzilla.redhat.com/1824861
Signed-off-by: Jakob Meng
---
NEWS
From: Jakob Meng
With the '--pretty' option, appctl.py will now print JSON output in a
more readable fashion, i.e. with additional line breaks, spaces and
sorted dictionary keys. The pretty-printed output from appctl.py is not
strictly the same as with ovs-appctl because of both use different
From: Jakob Meng
For monitoring systems such as Prometheus it would be beneficial if
OVS would expose statistics in a machine-readable format.
This patch introduces support for different output formats to ovs-xxx
tools, in particular ovs-appctl. The latter gains a global option
'-f,--format'
From: Jakob Meng
With the '--pretty' option, ovs-appctl will now print JSON output in a
more readable fashion, i.e. with additional line breaks, spaces and
sorted dictionary keys.
Signed-off-by: Jakob Meng
---
NEWS | 3 +++
lib/unixctl.c | 6 +++---
lib/unixctl.h
From: Jakob Meng
This patch introduces support for different output formats to the
Python code, as did the previous commit for ovs-xxx tools like
'ovs-appctl --format json dpif/show'.
In particular, tests/appctl.py gains a global option '-f,--format'
which allows users to request JSON instead of
From: Jakob Meng
This patch series is based on v7 [0] but applies three fundamental changes:
* When JSON output is requested but a command has not implemented JSON printing
yet, the plain-text output will be wrapped in a JSON object anyway. The main
reason is that commands, which have already
On 11/04/2024 14:24, Ilya Maximets wrote:
On 4/11/24 10:59, Chris Riches wrote:
From what we know so far, the DB was full of stale connection-tracking
information such as the following:
[...]
Once the host was recovered by putting in the timeout increase,
ovsdb-server successfully started
I tried to get this to thread under the "ovsdb-idl: potential issues
with the persistent UUID implementation" thread, but failed. This is
one potential solution to that which mirrors the current C IDL
implementation which seems to work for the most part, but relying on
the fact that hmaps allow
On 4/11/24 10:59, Chris Riches wrote:
> On 10/04/2024 23:31, Ilya Maximets wrote:
>> On 4/10/24 17:48, Chris Riches wrote:
>>> If the database is particularly large (multi-GB), ovsdb-server can take
>> Hi, Chris. May I ask how did you end up with multi-GB database?
>> I would understand if it was
On Wed, Apr 10, 2024 at 03:09:19PM +0100, Simon Horman wrote:
> The OvS primary development branch has been renamed main
> so there is no longer any need for CI configuration to
> refer to master.
>
> Signed-off-by: Simon Horman
>
> ---
> Simon Horman (2):
> appveyor: Remove reference to
On Thu, Apr 11, 2024 at 12:20 PM Vladislav Odintsov
wrote:
> Hi all,
>
> I’m running ovn 22.09 and sometimes see that ovn-controllers crash with
> segmentation fault. The backtrace is next:
>
> (gdb) bt
> #0 0x7f0742707de1 in __strlen_sse2 () from /lib64/libc.so.6
> #1 0x7f0742788c5d
On Wed, Apr 10, 2024 at 04:38:24PM -0500, Terry Wilson wrote:
> The Python persistent UUID tests should have the keyword "python"
> added so that TESTSUITEFLAGS="-k python" will not miss testing
> them.
>
> Fixes: 55b9507e6824 ("ovsdb-idl: Add the support to specify the uuid for row
> insert.")
On Thu, Apr 11, 2024 at 12:43:30AM +0200, Ilya Maximets wrote:
> 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
On Thu, Apr 11, 2024 at 12:43:29AM +0200, Ilya Maximets wrote:
> Missing and extra spaces, missing empty lines, unused imports and
> variables, long lines.
>
> Decided to just comment out the unused 'tail' and 'head' as they
> seem useful in documenting the meaning of the words.
>
> Files added
On Thu, Apr 11, 2024 at 12:43:28AM +0200, Ilya Maximets wrote:
> 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
Hi all,
I’m running ovn 22.09 and sometimes see that ovn-controllers crash with
segmentation fault. The backtrace is next:
(gdb) bt
#0 0x7f0742707de1 in __strlen_sse2 () from /lib64/libc.so.6
#1 0x7f0742788c5d in inet_pton () from /lib64/libc.so.6
#2 0x564f45a1c784 in ip_parse
On 10/04/2024 23:31, Ilya Maximets wrote:
On 4/10/24 17:48, Chris Riches wrote:
If the database is particularly large (multi-GB), ovsdb-server can take
Hi, Chris. May I ask how did you end up with multi-GB database?
I would understand if it was an OVN Southbound DB, for example,
but why the
On Thu, Apr 4, 2024 at 11:44 PM Ihar Hrachyshka wrote:
> Strictly speaking, this is not *essential* to start from MIN and not
> MIN+1 (once the hint reaches max, it will wrap back to MIN anyway), but
> this is inconsistent with how we handle datapath and port keys (we start
> with hint = 0
On Mon, Apr 8, 2024 at 1:06 PM Ilya Maximets wrote:
> Remaining bits from the OVS/OVN split.
>
> Fixes: 1af37d11be73 ("Remove XenServer Code")
> Signed-off-by: Ilya Maximets
> ---
> Documentation/tutorials/index.rst | 6 --
> README.rst| 3 ---
> acinclude.m4
48 matches
Mail list logo
