The IntOpt class supports choices argument since oslo.config 9.4.0[1].
[1] 83bbc0df4316e8a17b8417d02c80cd0cf5a8568e
Change-Id: I27b825d7b65b6c40692785b50c8a8ccc3ca80b73
According to the neutron API-REF [1] port's "binding:profile" field is
intended to be used for the "machine-machine communication for compute
services like Nova, Ironic or Zun to pass information to a Neutron
back-end." so it should be by allowed only for the users with the
SERVICE role granted, not even for ADMIN.
This patch updates that policies to be available only for SERVICE role
when new, secure RBAC policies are enabled.
Additionally this patch updates some policies for create, update and get
port APIs to make them all work in the same way and allow them for the
SERVICE users too.
Finally this new policy for create/update_port:binding:profile have to
be overwritten in the fullstack tests to be allowed also for admin user.
It is done by adding custom policy file for the fullstack tests only.
[1] https://docs.openstack.org/api-ref/network/v2/index.html#create-port
Closes-Bug: #2052937
Change-Id: I5c0094ff21439fe8977cfc623789a09067e6a895
api_workers=0 does not disable api workers but neutron-server still
launches one api worker. Rejecting 0 helps user notice that the value
they request in config files is not honored.
Also the other rpc workers options disable the corresponding workers
completely by setting these options to 0, so setting negative values
work but does not bring any special benefit.
Change-Id: Iac16b241c71ac1068c6fbea3cc792b74bfc66c03
Currently at least 1 rpc worker is launched even when a user requests
zero workers by setting rpc_workers=0. The setting of rpc_workers=0 is
used when ml2-ovn plugin is used without any additional agent, and in
this deployment pattern the single rpc worker is not at all used.
This change ensures no rpc worker is launched when rpc_workers options
is explicitly set to 0. This may be classified as a breaking change,
but is consistent with the earlier change[1] for rpc_workers=0.
[1] 3e1e2d63b3
Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
This config option was originally introduced before
the networking-ovn merge into neutron in 2019, and as
there is no usage it can be safely removed.
TrivialFix
Change-Id: I8ac826926dc8d3881ee57dc677f41bdbed00e5c0
This deprecated name for quota_rbac_policy was
introduced before 2016, and as there is no usage
according to codesearch it can be safely removed.
TrivialFix
Change-Id: I5cc3392985ee595999a5030e6b9c80a4c3009187
Prior to this patch, ML2/OVS and ML2/OVN had inconsistent IGMP
configurations. Neutron only exposed one configuration option for IGMP:
igmp_snooping_enabled.
Other features such as IGMP flood, IGMP flood reports and IGMP flood
unregistered were hardcoded differently on each driver (see LP#2044272
for a more details).
These hardcoded values has led to many changes over the years tweaking
them to work on different scenarios but they were never final because
the fix for one case would break the other.
This patch introduces 3 new configuration options for these other IGMP
features that can be enabled or disabled on both backends. Operators
can now fine tune their deployments in the way that will work for them.
As a consequence of the hardcoded values for each driver we had to break
some defaults and, in the case of ML2/OVS, if operators want to keep
things as they were before this patch they will need to enable the new
mcast_flood and mcast_flood_unregistered configuration options.
That said, the for ML2/OVS there was also an inconsistency with the help
string of igmp_snooping_enabled configuration option as it mentioned
that enabling snooping would disable flooding to unregistered ports but
that was not true anymore after the fix [0].
[0] https://bugs.launchpad.net/neutron/+bug/1884723
Closes-Bug: #2044272
Change-Id: Ic4dde46aa0ea2b03362329c87341c83b24d32176
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Support for the required DHCPv6 options was recently added in core
OVN with [1].
This patch adds support for that in ML2/OVN backend also and by that
closing one of the gaps between ML2/OVN and ML2/OVS backends.
This patch also adds upgrade check to check used ovn version and warn
operators if native OVN DHCP is used for BM provisioning and OVN version
is older than 23.06.0.
Unfortunately there is no easy way to check used version of OVN so check
relies on the ovnnb schema version.
[1] c5fd51bd15
Closes-Bug: #2030520
Change-Id: Iaa3ff8e97021e44f352e5a9a370714bf5f1d77b8
This was replaced a number of releases ago by the more
inclusive name 'vnic_type_prohibit_list', and is not used
anywhere in the tree.
Change-Id: Ifbe9f4cd0c291ab61e0adb93cfde866001086345
Each network type name is defined as a constant in neutron-lib. This
replaces the remaining string by the common constants.
This change ignores tests code because updating all test code brings
little gain while it touches huge number of lines.
Change-Id: I26ee715209d7d3f12c39c9e05d4fb9953b9b9537
The metadata_rate_limiting options were added during the previous
cycles[1] but these options were not added to the oslo.config entry
points thus are still missing from the example config files.
This change adds these options to the appropriate entry points so that
the options are picked up by oslo-config-generator.
These options were previously registered by metadata-agent which are
not using these options really. This change also removes that useless
registration.
[1] 5f4a41326d
Closes-Bug: #2044896
Change-Id: Ib4bea51e24063c275737cdd769ad07c621a845f6
This option has been marked deprecated since Ussuri
as it is a duplicate of OVS:integration_bridge, let's
remove it.
TrivialFix
Change-Id: I81bc5f3d98f752d926a243cbd17b8b894f2bdf58
The segment_mtu option was replaced with global_physnet_mtu
back in Mitaka, let's remove it as it's unused anywhere.
TrivialFix
Change-Id: Ib6e3ff7da700c2b312c7071734d0a5d498238eff
OVN added support for aging out MAC_Binding entries [1][2].
Without this feature, the MAC_Bindings table can grow indefinitely.
[1] 1a947dd307
[2] cecac71c0e
Closes-Bug: 2033932
Change-Id: I91070ad6addb30ffdedba5d561984d2f6626e2b7
This has actually never been used, it just migrated over
when the networking-ovn was integrated.
TrivialFix
Change-Id: I384a6f05e9fa08f419b82111639345aecede19df
This change re-implements validation of ipvN_ptr_zone_prefix_size at
config definition layer. This brings a few benefits.
- The validation is executed at an earlier stage
- The validation can be leveraged by the oslo-config-validator.
Change-Id: Ib72109bcb537b3e44719efb6f33ea46f0d45a1ef
These were deprecated during Xena cycle[1], so can be removed now.
[1] adfd853267
Related-Bug: #1927494
Change-Id: I9fadaa6cfcd66409da47422505c145d9d67f6b8c
In [1] we added support for FDB learning. In order to avoid issues
due to that table increasing without limits, which will impact OVN
performance, this patch is adding support for its aging mechanisms
which was added in OVN 23.09 in [2]. By default is disabled, so if
`localnet_learn_fdb` is enabled, the new configuration parameters
should be appropriately configured too: `fdb_age_threshold` and
`fdb_removal_limit`
[1] https://review.opendev.org/c/openstack/neutron/+/877675
[2] ae9a548882
Closes-Bug: 2035325
Change-Id: Ifdfaec35cc6b52040487a2b5ee08aba9282fc68b
The following resources have been updated with new policies for
tags:
* Port
* Subnet
* Network
* Router
* FloatingIP
* NetworkSegmentRange
* NetworkSegment
* SecurityGroup
* Trunk
* Subnetpool
The admin can now enforce specific policies for the resource tags
for the creation, update and deletion actions.
NOTE: a follow-up patch, with a new Launchpad bug reference, will
be created to move the ``Tagging`` class from
``ExtensionDescriptor`` to ``APIExtensionDescriptor``, and
refactor the ``TaggingController`` to be a standard
``neutron.api.v2.base.Controller``. Any API resource using
the second controller will use the path used by the wsgi
hooks, in particular the policy hook. That will make unnecessary
to manually call the ``policy.enforce`` method from the
extension class methods.
Closes-Bug: #2037002
Change-Id: I9f3e032739824f268db74c5a1b4f04d353742dbd
The patch introduces a new config section ovn_nb_global. All options
from this section are passed to OVN Northbound NB_Global table to
configure Northbound OVN.
First option is ignore_lsp_down to override OVN default configuration.
This option was changed in OVN to `true` [1] but for Neutron it's better
to not answer ARP packets when ports are in DOWN status.
[1] https://www.mail-archive.com/ovs-dev@openvswitch.org/msg60064.html
Change-Id: I478249cae483fd2540a7ff3ab714e3d9c3e13f17
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
The policy rule ``shared_security_group`` allows to create new policy
rules checking if a security group rule belongs or not to the project
default security group.
By default the behaviour has not changed. If an administrator wants
to prevent a non-privileged user from creating or deleting rules in the
default security group, the ``create_security_group_rule`` and
``delete_security_group_rule`` can be overriden. An example is provided
in the unit tests.
Closes-Bug: #2019960
Change-Id: I6c90b61df0e726ef07f177801069baf30c49de67
* get_subnet: the network owner can retrieve the subnet too.
* update_subnet: any project member can update the subnet.
* delete_subnet: any project member can delete the subnet.
Closes-Bug: #2038646
Change-Id: Iae2e3a31eb65d68dc0d3d0f9dd9fc8cf83260769
RBAC community wide goal phase-2[1] is to add service
role for the service APIs policy rule.
This patch adds new "service_api" role in policies, deprecates old rule
"context_is_advsvc" as this had basically same goal but for consistency
reasons we want now to have it named "service_api" as in other policies
for other projects.
This patch also adds unit tests to ensure what is allowed and what is
forbidden for the service role user.
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-2
Closes-Bug: #2026182
Change-Id: Iaa1a3a491d310c2304f6500c6e5d2b9c31a72fa8
When running behind a wsgi server like apache/mod_wsgi, neutron should
not register on Signals, it will overlap with the Signals registered by
the wsgi server.
Related-Bug: #2021814
Change-Id: I3c74846a8337d019f1ab6759ebb03f18c3f00238
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
Zuul