There are three reasons to revert this patch.
1. It broke RPC push API for trunks because it added port db model to
event payload that is not serializeable.
2. It also broke the callback event payload interface, which requires
that all entries in .states attribute belong to the same core object.
To quote from neutron-lib,
```
# an iterable of states for the resource from the newest to the oldest
# for example db states or api request/response
# the actual object type for states will vary depending on event caller
self.states = ...
```
3. There is no good justification why ml2/ovn would not allow this
operation. The rationale for the original patch was to align the
behavior with ml2/ovs, but we don't such parity requirements. The 409
error that can be returned by the API endpoints is backend specific.
To quote api-ref,
```
409 The operation returns this error code for one of these reasons:
A system configuration prevents the operation from succeeding.
```
AFAIU there is nothing that prevents ml2/ovn to create a trunk in this
situation.
This will have to be backported in all supported branches (the original
patch was backported down to Wallaby).
Conflicts:
neutron/services/trunk/drivers/ovn/trunk_driver.py
This reverts commit 833a6d82cd.
Closes-Bug: #2065707
Related-Bug: #2022059
Change-Id: I067c2f7286b2684b67b4389ca085d06a93f856ce
A recent change in neutron-lib [1] changed the behavior somewhat,
handling the None value explicitly passed as `allocation_pools` the same
way as if the field was not passed at all (meaning, setting pools from
start/end IP addresses for the subnet.)
This new behavior seems reasonable, so instead of reverting to the
original behavior, I'm making the test cases here not check an error
happens when None is passed.
[1] If768ab6a5f92d200841a734087bbc8fba8870dc6
Change-Id: I938ffabe7e74fa129c58dd4786153a0b4f374194
When neutron API is called to check requirements for the auto_allocate
topology, it needs to return not only 'tenant_id' field but also
'project_id' as that is required for the policy enforcement.
Without this 'project_id' field requirements check was failing for
member and reader users as they got 404 from the Neutron API. And the
reason why Neutron was returning 404 was that it wasn't passing policy
enforcement due to missing project_id field in the 'target' object.
Closes-bug: #2066369
Change-Id: Idf96a82bc6c8cb0b47dfde3baba94b42a8a8beba
This will guarantee that regardless of ovsdbapp version, Chassis_Private
will be deleted. This allows us to wait for a single event (DELETE) and
test the same behavior for all ovsdbapp versions. (Behavior of agent
listing when both Chassis and Chassis_Private records are deleted from
ovn db.)
Depends-On: https://review.opendev.org/c/openstack/requirements/+/920062
Change-Id: I0dfa21a927067afb532d7632f7e05427623327f5
ovsdbapp>=2.7.0 handles cleanup of Chassis_Private record
with chassis delete so we don't need explicit delete.
The compatibility part can be dropped when we update
requirements.txt to ovsdbapp>=2.7.0.
Closes-Bug: #2066263
Change-Id: I45c6e6a1c3536cf4f2d90b01a3577eec9eaf3743
The semantics changed since I2e3aa7c400d7bb17cc117b65faaa160b41013dde
but the name was not updated.
This patch also revealed a number of issues in unit tests where
mock flow_states were using the old key format (bare ip) instead of the
new (ip, mac) tuple. These are also now fixed.
Change-Id: Ic96b5ce6576c31075602e0f033fd74acbae333ee
There are currently two issues affecting the neutron gate, one
for pep8 job and the other for fullstack. We need to fix them
both together since they cannot merge separately.
Bump pylint to the latest version to fix pep8 job - it was
pinned to an old version which is causing the job to hang.
Do not use str(url) to stringify a URL for subsequent use
to fix the fullstack job. The str(url) function in SQLAlchemy
hides the password. For a URL string that is to be re-used, use
render_as_string(hide_password=False).
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Closes-Bug: #2065779
Change-Id: I8d04db91ddc2995fbff05b4c4c48baebcc418522
Instead of having a separate OVN command for deletion of each
static route, send out the deletion as a single command.
Which significantly improves the performance. Previously
deletion of 1000 routes took >1m30s and >6m30s for 2000 routes,
with this change it takes ~5s and ~8s, respectivily.
Closes-Bug: #2060054
Change-Id: Iaa5204e2e48795c31c502160041bd128189eef5a
If enable explicitly_egress_direct=True and set port as
no security group and port_security=False, the ingress
flood will reappear. The pipleline is:
Ingress
table_0 -> table_60 -> NORMAL -> VM
Egress
table_0 -> ... -> table_94 -> output
Because ingress final action is normal, the br-int will learn the
source MAC, but egress final action is output. So VM's mac will
never be learnt by the br-int. Then ingress flood comes again.
This patch adds a default direct flow to table 94 during the
openflow security group init and explicitly_egress_direct=True, then
the pipleline will be:
Ingress
table_0 -> table_60 -> table_94 -> output VM
Egress
table_0 -> ... -> table_94 -> output
And this patch adds the flows coming from patch port which will
match local vlan then go to table 94 do the same direct actions.
Above flood issue will be addressed by these flows.
Closes-Bug: #2051351
Change-Id: Ia61784174ee610b338f26660b2954330abc131a1
When the common Metadata Driver was created in [0], the
monitors dictionary was dropped accidentally. This causes
tracebacks in the fullstack L3-HA tests when
after_router_updated() is called. Put it back along with
its related tests.
[0] https://review.opendev.org/c/openstack/neutron/+/894399
Closes-bug: #2065145
Change-Id: I137ed7cec9e0eafdb3a351e5a414f5a0c16f33e5
If there were not changes made to data in the database there is no
reason to bump revision numbers because the underlying drivers won't
change too. This saves cycles in case empty updates are incoming to the
API.
Co-Authored-By: Ihar Hrachyshka <ihar@redhat.com>
Closes-bug: #2065094
Change-Id: Ib74fdab7a8927ef9cc24ef7810e9cf2c264941eb
Instead of each individual driver setting up the RPC server (and setting
the _rpc_backend attribute on the TrunkPlugin) we now check in the
TrunkPlugin if any driver requires the RPC backend to be started.
Additionally, we only start it when this is requested by Neutron via
start_rpc_listeners(). This is required when running neutron-server and
neutron-rpc-server separately to run RPC only in neutron-rpc-server.
As we still need the notifiers of ServerSideRpcBackend to be
created/started, we separate TrunkSkeleton (which is the RPC server
implementation) and ServerSideRpcBackend (which is essentially only a
notifier). In case RPC is required by a driver, we always start the
notifier, but the RPC server only when requested via
start_rpc_listeners().
Change-Id: I2c6362b3320e534a6e65bd7701b5ac2feca42a49
Closes-Bug: #2015275
Closes-Bug: #2062009
The semantics changed since I2e3aa7c400d7bb17cc117b65faaa160b41013dde
but the code was not updated to reflect it explicitly.
This patch modifies _update_flows_for_vlan_subr.
Change-Id: Id5e0d8bcc379f19dc85b23b4602be4e0e82f3d00
The tests were passing a string of IPv4 address where the actual code
was expecting a tuple of (IPv4 address, MAC address). The type of the
`addr` changed from a string to a tuple in:
I2e3aa7c400d7bb17cc117b65faaa160b41013dde
but the names of variables and the test cases were not.
Tests still didn't fail till recently because addr[0] resulted in the
first character of the IPv4 address string (e.g. `1`), and was then
interpreted by `netaddr` library as an address. This worked until
`netaddr>=1.0` started to enforce proper formats for passed IPv4
addresses - which broke the tests.
Closes-Bug: #2054435
Change-Id: Ib9594bc0611007efdbaf3219ccd44bbb37cfc627