Using OVN from packages was introduced in devstack via
https://review.opendev.org/c/openstack/devstack/+/763402
This change updates the sample files to make users aware of it,
especially when specifying the OVN branch to be used.
Change-Id: Ibfbdd712e49d1fb8522bcc39357be0f311ce3f5c
HAProxy supports hard stop [1] via SIGTERM signal. From the
documentation:
"""
... when the SIGTERM signal is sent to the haproxy process,
it immediately quits and all established connections are
closed.
"""
In case the process does not finish, the SIGKILL signal is sent.
The PID file created by the process is deleted.
[1]https://cbonte.github.io/haproxy-dconv/2.0/management.html#4
Closes-Bug: #1910691
Change-Id: Ifa3734e8eb4e52b1a132c3351ecc2e15463298bb
If security group API is disabled, there is no point to create default
security group for tenant when e.g. network is created.
Closes-Bug: #1913297
Change-Id: Ib73babdd563e3e8c21ce6f63456cc87af414c5aa
The translation marker _(..) wrapping a variable is meaningless
as no string is extracted and there is no way to translate them.
Only rare exception is the same string is defined in somewhere else
but I've never seen such situations so far.
In addition, we now only support translations in user-visible messages
used in API, so we can safely drop translation markers in exceptions
in the agent side.
Change-Id: Ie1d837d17bf50a4675bec4fe48ab13dde22ebdc2
Related-Bug: #1600788
When processing port events (create, update, delete), the port
provisioning (port creation) has priority over the other events [1].
As reported in the related bug, if a port deletion with an IP
address and another port creation with the same IP address arrive
to the DHCP agent, those events can be processed in the same queue.
Because of the creation event priority, even when this event arrived
after the deletion event, it will be processed first. That will
clash with the DHCP agent cache, that contains a port (not deleted
yet) with the same IP address. That will trigger an unwanted resync.
This patch implements a specific logic to store the events in
"ResourceProcessingQueue" (that uses "PriorityQueue" [2]). When
a port event arrives, the event comparison method checks the
(subnet, fixed_ips) tuple set of both elements. If there is a
coincidence, that means those ports are the same or are using
the same IP addreses (the race condition explained in the bug).
In this case, the priority is defined only by the timestamp;
that means the events are processed in order of arrival.
Because the Neutron server do not allow to have two ports in the
same subnet with the same IP address, the order of the events is
guaranteed. In the case explained in the bug, the deletion event
will be processed first.
[1]https://review.opendev.org/c/openstack/neutron/+/626830
[2]https://docs.python.org/3/library/queue.html#queue.PriorityQueue
Closes-Bug: #1913723
Change-Id: I89438feae3c0244f6da5e6a2a035d45b956ac247
In the unit tests of the dhcp linux driver module there are some
fake port classes defined.
Some of them had duplicate assignement of the device_owner, once
it was set to some constant value and later it was assignment with
some value given as an __init__'s argument.
This patch removes setting constant value. We can always accept
value given as input argument.
TrivialFix
Change-Id: Iff47cf1646fc99fd5a1bf4ff5498d4a15f9d9d68
Tell something about the config option ``explicitly_egress_direct``
since there is something not so much clear for users now.
Change-Id: I1c046d8140f93d9a8cd9e0bc43d3494e4f6a1ce7
In some scenario, dvr router interface will try to ARP some device
which is not hosted in the same host. When the ARP request send
out, the ethernet source MAC will be changed to dvr_host_mac. Then
thoses devices will reply ARP with the dvr_host_mac in ethernet dest
MAC. So finally the dvr router interface will drop this, and the ARP
get failed.
This patch adds one flow for this, it will match the dest MAC, ARP
op-code=2 and arp_tha address, then change the dest MAC to the right
router interface's MAC address.
Closes-Bug: #1913646
Related-Bug: #1859638
Change-Id: Ibc7f01450a3da026ca5c4fb667dada912cf472e3
It's easier to check what was wrong if jobs in periodic queue
are voting.
It will not block any development so it is safe to do that.
Change-Id: I038f83afb1fd47de8570f526e594c4c69f4bfe19
We need to fix bug [1] and then make this job voting again.
But for now lets unblock the gate by making it non-voting
temporary.
[1] https://bugs.launchpad.net/neutron/+bug/1913718
Change-Id: I1129132967895cd59b0576db82a2ff659c778493
Related-Bug: #1913718
get_schema_helper() makes a direct short-lived connection to the
ovsb-server to grab the running schema before we initiate a
connection for the Idl. Moving the schema retrieving code out of
the path of starting the connection allows us to adjust to the
ovsdb-server's schema version at driver init instead of having to
set it in post_fork_initialize().
One benefit of this is that Events can be more easily defined to
watch for a table which might change depending on the schema, e.g.
Chassis vs Chassis_Private.
Change-Id: Ia3dd792f4335fcde0df7d11e6aaf693dd9611bb6
The 'timeout' parameter needs to be passed to wait_until_true
to make it meaningful and change it to 60 as a default timeout.
In fact 60sec was used till now.
Signed-off-by: Yalei Li <liyl43@chinatelecom.cn>
Change-Id: I2881647e126ab48fa3381543a785ec037866de64
This patch is fixing the code which retrieves the datapath type of
the integration bridge. The query to the OVS IDL was never executed
and the comparison was wrong, hence failing to determine when
to apply the iptables rules on DPDK scenarios introduced by [0].
[0] 26a30a3b78
Related-Bug: #1904871
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
Change-Id: I25147f676a5f22536888e72f21deee23c13063b6
In some of the UT for keepalived module, this check function wasn't
mocked so tests were failing on node where keepalived was actually
installed and was supporting "no_track" option.
Closes-Bug: #1913280
Change-Id: I0d20186a69d884b0b7912838f28d401ce4610d29