Read the chassis bandwidth configuration (stored in the "Chassis"
registers) only once, in the maintenance worker. The SB synchronizer
will call the OVN client Placement extension
"read_initial_chassis_config" method.
This new approach changes how the Placement information is stored. The
Placement extension does not store anymore a local cache of the
resource providers. Instead of this, in future patches, when this
information is required, the Placement extension will retrieve this
information from the SB DB, reading the content from the "Chassis"
registers and parsing the values.
Partial-Bug: #1578989
Change-Id: I160b1dda85596277125c532ea4ce4df8e4d25b63
Today the sriov qos service plugin blindly blocks creating ports
with minimum bandwidth qos and with direct_physical vnic_type. This was
originally added when only dataplane enforcement was the scope of the
qos service plugin. However in the last many releases we created
placement enforcement for this qos rule regardless of the vnic_type.
So now blindly blocking the port creation is now preventing using the
placement enforcement for this rule for direct_physical ports.
This patch removes this limitation by marking minimum bandwidth as
supported rule for the sriov qos service plugin. The limitation that
data plane enforcement is not supported for this rule remains. The agent
will not even try to apply any kind of rules to these ports as port
binding is not forwarded for the sriov agent at all.
The documentation is extended to explain that placement enforcement now
works while data plane enforcement still not supported.
This is somewhat similar to the case when the support for egress
direction is added to the minimum bandwidth rule, while the sriov data
plane enforcement was not (could not) been implemented for this
direction in the sriov agent. Today the sriov agent simply ignores the
egress direction rules in the minimum bandwidth qos rule during applying
the data plane enforcement.
Closes-Bug: #1949877
Change-Id: I20ad32eac414ff90b551bff940d92cbcfa848101
Added a new OVN Client extension: OVNClientPlacementExtension. This
extension is in charge of handling the bandwidth information stored
in the OVN database, in the "Chassis" registers on the
"ovn-cms-options" dictionary.
Three new keys are created to store the resource provider information
needed to parameterize the network backend bandwidth information,
following the implementation done in OVS and SR-IOV:
- resource_provider_bandwidths
- resource_provider_inventory_defaults
- resource_provider_hypervisors
When the OVN Client is started, the Placement extension will check if
the "placement" extension is loaded. It will also create an event to
check any configuration change done in any "Chassis" register.
The Placement extension will read the initial configuration stored
in the OVN database and will populate it to Placement API, creating
the needed resource providers, traits and inventories.
NOTE: This patch belongs to a series of patches to implement
minimum bandwidth scheduling blueprint in OVN backend. The next
patch will make OVN backend scheduling aware using the information
stored in Placement API and the port information passed by Nova when
a VM is created.
NOTE: this patch improves [1], fixing the error [2] reported in [3].
[1]https://review.opendev.org/c/openstack/neutron/+/776701
[2]https://paste.opendev.org/show/807614/
[3]https://launchpad.net/bugs/1936983
Partial-Bug: #1578989
Change-Id: I63e81aebce2621226ff2cfe91f16c97913c137e8
This patch does *not* implement dataplane enforcement.
QoS minimum packet rate rule is enabled in OVS backend driver and
create/delete/update empty methods are added to enable placement
enforcement.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ie283ad3a4ec433c88ac23f798908cd143159394b
The OVN driver needs to announce all DNS extensions as supported,
otherwise the neutron server will reject them.
Closes-Bug: 1947127
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Ic269902ef7a16893c4ea624b04347d04db4f52d9
This patch adds information about what "A", "M" and "O"
means in the ra_mode and and address_mode table.
It also changes from the "radvd" to the "neutron-generated
advertisements" in the same table as "radvd" is an implementation.
Change-Id: I66e2815e451a6940402d49240ec743f99785850c
This patch implements support for CRUD operations for QoS minimum
packet rate, for example:
DELETE /qos/policies/$POLICY_ID/minimum_packet_rate_rules/$RULE_ID
Placement or dataplane enforcement is not implemented yet.
Partial-Bug: #1922237
See-Also: https://review.opendev.org/785236
Change-Id: Ie994bdab62bab33737f25287e568519c782dea9a
This patch adds info about workaround how to spawn VM using Security
Groups shared through RBAC mechanism in Neutron.
Proper fix for that issue will require changes in the Neutron API and in
Nova so will not be possible to backport.
Related-bug: #1942615
Change-Id: Iadb3fe0ca8fa9c14ec2912016bd3912e5dcee5ff
This patch adds the documentation to the Network Availability Zones
support in OVN. Instead of having two documentation pages, one for router
AZs and another one for network AZs, this patch merges both guides into
one single documentation. Setting up AZs in OVN is the same for both
types and the differences between the two are documented within their
own sections.
The patch also removes a limitation listed in the SR-IOV documentation
for OVN since we no longer have a default HA Chassis Group. This
limitation was removed as part of the Network AZ work.
Change-Id: I55f27a5473dcd1e6e2255007108c2008acfb6dec
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
The quota driver ``ConfDriver`` was deprecated in Liberty release.
``NullQuotaDriver`` is created for testing although it could be used
in production if no quota enforcement is needed. However, because
the Quota engine is not plugable (is an extension always loaded), it
could be interesting to make it plugable as any other plugin.
This patch also creates a Quota engine driver API class that should be
used in any Quota engine driver. Currently it is used in the three
in-tree drivers implemented: ``NullQuotaDriver``, ``DbQuotaDriver``
and ``DbQuotaNoLockDriver``.
Change-Id: Ib4af80e18fac52b9f68f26c84a215415e63c2822
Closes-Bug: #1928211
There are a number of extensions that were removed from the vmware-nsx
package as part of the removal of NSX-MH support in 15.0.0 (October
2019) [1]. We don't need to keep references to these. You can prove this
by grepping for the various references config options in the current
source tree and using 'git log -S' to find the patches that removed
things.
[1] 26135f34ac
Change-Id: I6f4489b14b164e4699a600acac84065dfe1231dc
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This reverts commit df5cb28737453e2dfee17e177160fa6d7a59b7e0.
The reverted commit triggers the failure of tempest-slow-py3 job.
tempest-slow-py3 is equal to non-voting neutron-ovn-tempest-slow job
in the neutron CI. It is a non-voting job so the error was not detected
before merging it. To recover the tempest job in OpenStack wide,
this commit reverts it.
See http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023764.html
Closes-Bug: #1936983
Change-Id: Id8cdd9c69e4fef2d9c335447b498958add8b7816
Added a new OVN Client extension: OVNClientPlacementExtension. This
extension is in charge of handling the bandwidth information stored
in the OVN database, in the "Chassis" registers on the
"ovn-cms-options" dictionary.
Three new keys are created to store the resource provider information
needed to parameterize the network backend bandwidth information,
following the implementation done in OVS and SR-IOV:
- resource_provider_bandwidths
- resource_provider_inventory_defaults
- resource_provider_hypervisors
When the OVN Client is started, the Placement extension will check if
the "placement" extension is loaded. It will also create an event to
check any configuration change done in any "Chassis" register.
The Placement extension will read the initial configuration stored
in the OVN database and will populate it to Placement API, creating
the needed resource providers, traits and inventories.
NOTE: This patch belongs to a series of patches to implement
minimum bandwidth scheduling blueprint in OVN backend. The next
patch will make OVN backend scheduling aware using the information
stored in Placement API and the port information passed by Nova when
a VM is created.
Partial-Bug: #1578989
Change-Id: I8ba38b8ace8852009fba8712aafa9f88c2b93ccb
This extension should be enabled with ML2/OVN backend also but
recent changes in how supported extensions are calculated ([1])
it was filtered out.
[1] https://review.opendev.org/c/openstack/neutron/+/793141
Closes-Bug: #1933954
Change-Id: Ic8ab322683e72101a8f797b108bf23bc169092cb
This API extension is supported by ML2 plugin and is database only
thing. So there is no need to filter it out when OVN backend is used.
Related-Bug: #1933115
Change-Id: Ica4490d3ec36e227301e3f3a7b093750b2e18b83
MTU configured inside instances which are connected to the networks
with enabled transparent vlan needs to have MTU set to 4 bytes less
than it is provided by DHCP to make space for additional vlan
header.
This is required only if instance will have some vlan tagged interfaces
configured.
Closes-bug: #1906318
Change-Id: Ia6691cbe35a1e874857ec94660ac4b1850586305
Migration to/from the DVR HA router is now supported
from/to all other router types. All is tests in the
neutron_tempest_plugin.scenario.test_migration module.
Change-Id: Ib156b330c12f75bdb436e64c777425acaf7a9067
In fact this API extension is independent of the mech driver and should
be listed as supported by the OVN mech driver to not be filtered out
from the list of actually available extensions.
Related-Bug: #1929676
Change-Id: Ie2d5c52ce09b1b366717830f0af53f26366ee4b8