diff options
Diffstat (limited to 'releasenotes')
4 files changed, 86 insertions, 0 deletions
diff --git a/releasenotes/notes/bug-1953165-6e848ea2c0398f56.yaml b/releasenotes/notes/bug-1953165-6e848ea2c0398f56.yaml new file mode 100644 index 0000000000..6c79c0daef --- /dev/null +++ b/releasenotes/notes/bug-1953165-6e848ea2c0398f56.yaml @@ -0,0 +1,16 @@ +--- +issues: + - | + The high availability of metadata service on isolated networks is limited + or non-existent. IPv4 metadata is redundant when the DHCP agent managing + it is redundant, but recovery is tied to the renewal of the DHCP lease, + making most recoveries very slow. IPv6 metadata is not redundant at all + as the IPv6 metadata address can only be configured in a single place at + a time as it is link-local. Multiple agents trying to configure it will + generate an IPv6 duplicate address detection failure. + + Administrators may observe the IPv6 metadata address in "dadfailed" state + in the DHCP namespace for this reason, which is only an indication it is + not highly available. Until a redesign is made to the isolated metadata + service there is not a better deployment option. See `bug 1953165 + <https://bugs.launchpad.net/neutron/+bug/1953165>`_ for information. diff --git a/releasenotes/notes/enable-enforce-scope-and-new-defaults-1f82a9eb71125f5d.yaml b/releasenotes/notes/enable-enforce-scope-and-new-defaults-1f82a9eb71125f5d.yaml new file mode 100644 index 0000000000..5ca899343e --- /dev/null +++ b/releasenotes/notes/enable-enforce-scope-and-new-defaults-1f82a9eb71125f5d.yaml @@ -0,0 +1,25 @@ +--- +upgrade: + - | + The Neutron service enable the API policies (RBAC) new defaults and scope + by default. The Default value of config options + ``[oslo_policy] enforce_scope`` and + ``[oslo_policy] oslo_policy.enforce_new_defaults`` have been changed + to ``True``. + + This means if you are using system scope token to access Neutron API then + the request will be failed with 403 error code. Also, new defaults will be + enforced by default. To know about the new defaults of each policy + rule, refer to the `Policy New Defaults`_. For more detail about + the Neutron API policies changes, refer to `Policy Concepts`_. + + If you want to disable them then modify the below config options value in + ``neutron.conf`` file:: + + [oslo_policy] + enforce_new_defaults=False + enforce_scope=False + + .. _`Policy New Defaults`: https://docs.openstack.org/neutron/latest/configuration/policy.html + .. _`Policy Concepts`: https://docs.openstack.org/neutron/latest/contributor/internals/policy.html + diff --git a/releasenotes/notes/localnet-learn-fdb-22469280b49701fc.yaml b/releasenotes/notes/localnet-learn-fdb-22469280b49701fc.yaml new file mode 100644 index 0000000000..9af9ca48be --- /dev/null +++ b/releasenotes/notes/localnet-learn-fdb-22469280b49701fc.yaml @@ -0,0 +1,23 @@ +--- +issues: + - | + In OVN 22.09 the option "localnet_learn_fdb" was added, enabling localnet + ports to learn MAC addresses and store them at the FDB table. + There is no aging mechanism for those MACs (that is the reason for not + having this option enabled by default) and therefore it needs to be used + with care, specially when provider networks are big. It is recommended to + perform periodic manual cleanups of FDB table, to avoid scalability + issues -- until OVN implements an aging mechanism for this, tracked at + https://bugzilla.redhat.com/show_bug.cgi?id=2179942. +fixes: + - | + By default localnet ports don't learn MAC addresses and therefore they are + not stored in the FDB table at OVN SB DB. This leads to flooding issues + when the destination traffic is an unknown IP by OpenStack. In OVN 22.09 + the option "localnet_learn_fdb" was added, enabling those ports to learn + MAC addresses and store them at the FDB table. Note there is no aging + mechanism for those MACs, thus this is not enabled by default and needs + to be used carefully, specially when provider networks are big, and/or + performing manual cleanup of FDB table over time to avoid scalability + issues, until OVN implements it at + https://bugzilla.redhat.com/show_bug.cgi?id=2179942. diff --git a/releasenotes/releasenotes/notes/network_subnet_mtu_validation-c221f22efcfae927.yaml b/releasenotes/releasenotes/notes/network_subnet_mtu_validation-c221f22efcfae927.yaml new file mode 100644 index 0000000000..f30421c61a --- /dev/null +++ b/releasenotes/releasenotes/notes/network_subnet_mtu_validation-c221f22efcfae927.yaml @@ -0,0 +1,22 @@ +--- +fixes: + - | + The Neutron API has been changed to validate network MTU minimums. + A network's MTU is now only valid if it is the minimum value + allowed based on the IP version of the associated subnets, + 68 for IPv4 and 1280 for IPv6. + + This minimum is now enforced in the following ways: + + * When a subnet is associated with a network, validate + the MTU is large enough for the IP version. Not only + would the subnet be unusable if it was allowed, but the + Linux kernel can fail adding addresses and configuring + network settings like the MTU. + + * When a network MTU is changed, validate the MTU is large + enough for any currently associated subnets. Allowing a + smaller MTU would render any existing subnets unusable. + + See bug `1988069 <https://bugs.launchpad.net/neutron/+bug/1988069>`_ + for more information. |