On 15 Mar 2024, at 18:59, Eric Garver wrote:
> On Fri, Mar 15, 2024 at 12:37:54PM -0400, Eric Garver wrote:
>> On Fri, Mar 15, 2024 at 04:55:50PM +0100, Eelco Chaudron wrote:
>>>
>>>
>>> On 11 Mar 2024, at 18:51, Eric Garver wrote:
>>>
Kernel support has been added for this action. As such,
> 2024年3月16日 上午9:17,Ilya Maximets 写道:
>
> On 2/23/24 04:37, Daniel Ding wrote:
>> After running ovs-tcpdump and inputs multiple CTRL+C, the program will
>> raise the following exception.
>>
>> Error in atexit._run_exitfuncs:
>> Traceback (most recent call last):
>> File "/usr/bin/ovs-tcpdump"
The OVN Controller currently uses unicast messages when
communicating with the DHCPv6 server.
This is at odds with RFC 3315 paragraph 1 in each of the sections
18.2.1, 18.2.3, 18.2.6, and 18.2.7.
The client is expected to use multicast, unless the server has
explicitly told it to use unicast usin
The current code puts the contents of the ``ipb6_ra_pd_list``
option verbatim into the ``ipv6_ra_prefixes`` option.
This does not work, because the ``ipv6_ra_pd_list`` is not an IPv6
prefix, but a string composed of aid:prefix/length, and as a
consequence the controller would log a message like th
On Sat, Mar 09, 2024 at 10:34:57AM -0800, Jakub Kicinski wrote:
> The only legit reason I could think of for net/genetlink.h
> and linux/genetlink.h to be separate would be if one was
> included by other headers and we wanted to keep it lightweight.
> That is not the case, net/openvswitch/meter.h i
Hi Roberto,
I have some concerns about this patch. Let's use the test case you added
as an example network. Let's bind the vms and DGPs to hypervisors:
* vm1 and lr1-ts1 are bound to hypervisor hv1
* vm2 and lr1-ts2 are bound to hypervisor hv2
Now imagine a packet arrives on lr1-ts1. The pack
On Fri, Mar 15, 2024 at 09:14:49PM +0100, Ilya Maximets wrote:
> Each cluster member typically always transfers leadership to the same
> other member, which is the first in their list of servers. This may
> result in two servers in a 3-node cluster to transfer leadership to
> each other and never
On 3/18/24 17:15, Felix Huettner wrote:
> On Fri, Mar 15, 2024 at 09:14:49PM +0100, Ilya Maximets wrote:
>> Each cluster member typically always transfers leadership to the same
>> other member, which is the first in their list of servers. This may
>> result in two servers in a 3-node cluster to t
Thank you Mohammad and Ales. I pushed this change to main.
On 2/28/24 01:36, Ales Musil wrote:
On Mon, Feb 26, 2024 at 2:11 PM Mohammad Heib wrote:
Expose the igmp/mld group protocol version through the
IGMP_GROUP table in SBDB.
This patch can be used by ovn consumer for debuggability purpos
Thank you Mohammad and Ales, I pushed this to main, and all branches
back to branch-23.06.
On 3/6/24 01:24, Ales Musil wrote:
On Mon, Feb 26, 2024 at 2:55 PM Mohammad Heib wrote:
ovn-controller immediately removes the vport_bindings requests that were
generated by VIFs after handling them lo
Thank you Igor and Ales, I pushed this to main.
On 3/6/24 01:28, Ales Musil wrote:
On Thu, Feb 29, 2024 at 5:43 PM Igor Zhukov wrote:
I noticed the copyright year at the bottom of
https://docs.ovn.org/en/latest/contents.html
Signed-off-by: Igor Zhukov
---
Documentation/conf.py | 2 +-
1
Thanks!
Acked-by: Mark Michelson
I went ahead and pushed this to main.
On 2/29/24 17:40, amgin...@gmail.com wrote:
From: Aliasgar Ginwala
Setting up OVN on new kernel bumps openssl version.
Since OVS PKI infrastructure that generated older ssl certs based on
old openssl version, raft fails
Thanks for finding and fixing this!
Acked-by: Mark Michelson
On 3/4/24 23:54, Igor Zhukov wrote:
I found the broken link at
https://docs.ovn.org/en/latest/internals/release-process.html.
I believe the correct link is https://www.ovn.org/en/releases/#long-term-support
Signed-off-by: Igor Zhu
I merged this change to main. I then evaluated about whether this should
be backported to other branches and decided that yes, this should be. So
I backported it to all branches back to 23.06.
On 3/8/24 10:30, Mark Michelson wrote:
Thanks Ales, it looks good to me.
Acked-by: Mark Michelson
Hi Han,
I have a comment below
On 3/5/24 01:27, Han Zhou wrote:
The ovn-ofctrl-wait-before-clear setting is designed to minimize
downtime during the initial start-up of the ovn-controller. For this
purpose, the ovn-controller should wait only once upon entering the
S_WAIT_BEFORE_CLEAR state for
Thanks for the rebase Ales. I merged the entire series to main.
On 3/15/24 13:38, Ales Musil wrote:
This series has the remaing patches that weren't yet
accepted with addition that fixes table numbers in comments.
A lot of tests were relying on exact table numbers for
flow comparison either log
Thanks Xavier and Ales,
I pushed both patches to main.
On 3/15/24 14:07, Xavier Simonart wrote:
This patch uses the recently introduced macros defining openflow table numbers.
Signed-off-by: Xavier Simonart
---
v2: - Handled Ales' comments (i.e. fix few remaining hard-coded numbers)
- R
Thanks Frode, looks good to me.
Acked-by: Mark Michelson
On 3/18/24 07:42, Frode Nordahl wrote:
The OVN Controller currently uses unicast messages when
communicating with the DHCPv6 server.
This is at odds with RFC 3315 paragraph 1 in each of the sections
18.2.1, 18.2.3, 18.2.6, and 18.2.7.
The prefix we obtain is used to fill the ``ipv6_ra_prefixes``
option for configuration of instances through SLAAC.
As discussed in RFC 7421 the interface identifier is 64 bits long,
and client implementations refrain from performing SLAAC with any
other prefix length.
TODO: I'm pretty sure the or
Thanks Frode, looks good to me.
Acked-by: Mark Michelson
On 3/18/24 07:43, Frode Nordahl wrote:
The current code puts the contents of the ``ipb6_ra_pd_list``
option verbatim into the ``ipv6_ra_prefixes`` option.
This does not work, because the ``ipv6_ra_pd_list`` is not an IPv6
prefix, but a
Fedora received an update of netcat to version 7.94, this version
brings ability for UDP to accept multiple connections without closing
(-k/--keep-open) [0]. That had negative impact on the tests as the UDP
netcat server was closing sooner that expected.
Make sure that the server is alive when we
The way how tcpdump was called in tests was inconsistent,
a lot fo the tests didn't even wait for the tcpdump to properly
start, some of them didn't redirect the stderr which could cause
leak into the test stderr and fail the test.
To prevent that add macro that starts tcpdump and properly
waits f
22 matches
Mail list logo