summaryrefslogtreecommitdiff
path: root/releasenotes
Commit message (Collapse)AuthorAgeFilesLines
...
* | Update tap ip in metadata agent when metadata port ip updatedhailun.huang2022-11-211-0/+6
|/ | | | | | | | | | Update neutron-ovn-metadata-agent, catch port_binding update event of monitoring localport type, and judge if the neutron:cidrs field in the external_ids of port_binding table has changed, then update_datapath. Closes-Bug: #1996677 Change-Id: Ibdc1b385b07a2ab1ca8e4b6278f6d39fb5839509
* [OVN] Set the default OVN metadata worker number to 0Rodolfo Alonso Hernandez2022-10-051-0/+9
| | | | | | | | | | | | | If the configuration variable ``metadata_workers`` is not set, the default value for ML2/OVN mechanism driver will be zero. This value defines the number of separate workers that will be spawned by the OVN metadata agent. By default, the OVN metadata proxy handler will be executed inside the same OVN metadata agent process, in a parallel thread. That reduces the number of OVN SB database connections to one. Related-Bug: #1993181 Change-Id: I8bc4f2784ccefe6078506bc27cc7a98c48192ad2
* Merge "Since OVN 20.06, config is stored in "Chassis.other_config""Zuul2022-10-111-0/+10
|\
| * Since OVN 20.06, config is stored in "Chassis.other_config"Rodolfo Alonso Hernandez2022-10-041-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since OVN 20.06 [1], the OVN configuration is stored in "Chassis.other_config". Since OVN 22.09, the "Chassis" configuration stored in "Chassis.other_config" will not be replicated to "Chassis.external_ids". The ML2/OVN plugin tries to retrieve the "Chassis" configuration from the "other_config" field first; if this field does not exist (in OVN versions before 20.06), the plugin will use "external_ids" field instead. Neutron will be compatible with the different OVN versions (with and without "other_config" field). [1]https://github.com/ovn-org/ovn/commit/74d90c2223d0a8c123823fb849b4c2de58c296e4 [2]https://github.com/ovn-org/ovn/commit/51309429cc3032a0cb422603e7bbda4905ca01ae NOTE: this patch is similar to [1], but in this case neutron keeps compatibility with the different OVN versions (with and without "other_config" field). Since [2], the Neutron CI has a new job that uses the OVN/OVS packages distributed by the operating system installed by the CI (in this case, Ubuntu 20.04 and OVN 20.03). [1]https://review.opendev.org/c/openstack/neutron/+/859642 [2]https://review.opendev.org/c/openstack/neutron/+/860636 Closes-Bug: #1990229 Change-Id: I54c8fd4d065ae537f396408df16832b158ee8998
* | dhcp: add/use cleanup stale devices APISahid Orentino Ferdjaoui2022-10-111-0/+5
|/ | | | | | | | | | | | | | | | This is adding new API for the dhcp driver to clean stale devices. Previously it was not necessary since a dhcp port was related to a nemaspace and when the namespace got deleted, the device was also removed. Now with multisegments we can have more than one dhcp port per namespace based on segmenation id so we should ensure to remove the stale device. Partial-Bug: #1956435 Partial-Bug: #1764738 Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com> Change-Id: I4a46b034a5feabb914bc6fd121d68e20278230b5
* Revert "Since OVN 20.06, config is stored in "Chassis.other_config""Rodolfo Alonso2022-10-061-13/+0
| | | | | | | | | | This reverts commit f8fa909444cf87d55819fa9dbc45ed77cff7b845. Reason for revert: Because the OpenStack CI OS (Ubuntu 20.04) still doesn't support OVN > v20.03, we need to revert this patch until the CI migrates to Ubuntu 22.04 Change-Id: Iafd0ce629bf3a93454f4e322780d3b2f911363f8 Closes-Bug: #1991962
* Since OVN 20.06, config is stored in "Chassis.other_config"Rodolfo Alonso Hernandez2022-09-301-0/+13
| | | | | | | | | | | | | | | | | | | Since OVN 20.06 [1], the OVN configuration is stored in "Chassis.other_config". Since OVN 22.09, the "Chassis" configuration stored in "Chassis.other_config" will not be replicated to "Chassis.external_ids". This patch replaces any reference to "external_ids" when retrieving the Chassis configuration. That means Neutron no longer supports OVN versions below 20.06. [1]https://github.com/ovn-org/ovn/commit/74d90c2223d0a8c123823fb849b4c2de58c296e4 [2]https://github.com/ovn-org/ovn/commit/51309429cc3032a0cb422603e7bbda4905ca01ae Closes-Bug: #1990229 Change-Id: If379cefb66a262318858e1cea6503aa3a56ba956
* Imported Translations from ZanataOpenStack Proposal Bot2022-09-173-4/+194
| | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I0b325b13dfeb3f83455b2b6727e386eeee1d4852
* Update master for stable/zedOpenStack Release Bot2022-09-162-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/zed. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/zed. Sem-Ver: feature Change-Id: I9a1311eb60be490ba589baa6a4df6ceb7f7a2d4f
* Imported Translations from ZanataOpenStack Proposal Bot2022-09-161-8/+134
| | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I10c66d682682a1b0ab9367d7ae638dced0f90d15
* Add an active wait during the port provisioning eventRodolfo Alonso Hernandez2022-08-311-0/+8
| | | | | | | | | | | | | | | | | | | | In ML2/OVN, during a live-migration process, it could happend that the port provisioning event is received before the port binding has been updated. That means the port has been created in the destination host and the event received (this event will remove any pending provisioning block). But the Nova port binding request has not arrived yet, updating the port binding registers. Because the port is considered "not bound" (yet), the port provisioning doesn't set the port status to ACTIVE. This patch creates an active wait during the port provisioning event method. If the port binding is still "unbound", the method retries the port retrieval several times, giving some time to the port binding request from Nova to arrive. Closes-Bug: #1988199 Change-Id: I50091c84e67c172c94ce9140f23235421599185c
* Merge "Allow operator to disable usage of random-fully"Zuul2022-08-261-0/+15
|\
| * Allow operator to disable usage of random-fullyDavid Hill2022-08-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some specific use case, the cloud operator expects the source port of a packet to stay the same across all masquerading layer up to the destination host. With the implementation of the random-fully code, this behavior was changed as source_port is always rewritten no matter which type of architecture / network CIDRs is being used in the backend. This setting allows a user to fallback to the original behavior of the masquerading process which is to keep the source_port consistent across all layers. The initial random-fully fix prevents packet drops when duplicate tuples are generated from two different namespace when the source_ip:source_port goes toward the same destination so enabling this setting would allow this issue to show again. Perhaps a right approach here would be to fix this "racey" situation in the kernel by perhaps using the mac address as a seed to the tuple ... Change-Id: Idfe5e51007b9a3eaa48779cd01edbca2f586eee5 Closes-bug: #1987396
* | Merge "Script to remove duplicated port bindings"Zuul2022-08-241-0/+10
|\ \ | |/ |/|
| * Script to remove duplicated port bindingsRodolfo Alonso Hernandez2022-08-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new script to remove the duplicated port bindings was added. This script will list all ``ml2_port_bindings`` records in the database, finding those ones with the same port ID. Then the script removes those ones with status=INACTIVE. This script is useful to remove those leftovers that remain in the database after a failed live migration. "dry_run" mode is possible if selected in "[cli_script] dry_run" boolean config option. The duplicated port bindings are printed in the shell but not deleted. Related-Bug: #1979072 Change-Id: I0de5fbb70eb852f82bd311616557985d1ce89bbf
* | Merge "[OVN][QoS] Add minimum bandwidth rule support to ML2/OVN"Zuul2022-08-221-0/+6
|\ \
| * | [OVN][QoS] Add minimum bandwidth rule support to ML2/OVNRodolfo Alonso Hernandez2022-08-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for QoS egress minimum bandwidth rules in ML2/OVN. The enforcement is done in the network backend. Since [1], in v22.06.0, OVN is capable of guarantee a minimal bandwidth for a logical switch port. The enforcement of this rule is done in the physical bridge interface. [1]https://github.com/ovn-org/ovn/commit/dbf12e5fe1f7ab2acef4152854c239b999b70188 Closes-Bug: #1982951 Change-Id: Ia3831b18463c29f676c253edb64419667b5f2c0b
* | | [OVN] Fix updating network segmentation IDLucas Alvares Gomes2022-08-101-0/+7
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ML2/OVN driver wasn't handling updates to the segmentation ID for a given network. This patch fixes this problem. This patch extends the _update_segmentation_id() method to check on drivers which does not inherits from AgentMechanismDriverBase, which is the case of OVN (which inherits from MechanismDriver). A new method is now called for those drivers to get a list of supported VIF types, called get_supported_vif_types(). Closes-Bug: #1944708 Change-Id: Ibe08bfbc2efc55b9d628cdd0605941b7486186b6 Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
* | Merge "Forbid create ndp proxy on same router with same ip address"Zuul2022-07-201-0/+6
|\ \
| * | Forbid create ndp proxy on same router with same ip addressyangjianfeng2022-06-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create multiple ndp proxies with same ip address within one router is invalid. The related database constraint was missed in previous patchsets. The patch add some codes fixed this error. Additionally, Fixed two typo errors. Related-Bug: #1877301 Change-Id: Iab24ad78a3d4d9b0ee584cf0986328c9ae2bd16a
* | | Add release note for OVN "requested-chassis" featureRodolfo Alonso Hernandez2022-07-071-0/+8
| |/ |/| | | | | | | | | | | | | | | | | This patch adds the missing release note for [1]. [1]https://review.opendev.org/c/openstack/neutron/+/828455/6 Trivial-Fix Change-Id: I544128e0e4813acd851b5e48b4c352c3fb62c869
* | Implement experimental features frameworkMiguel Lavalle2022-06-301-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the Zed PTG it was decided to handle unsupported features in Neutron as experimental. See section titled "When we say something is not supported?", day 2 in [1]. The agreement was: "We keep existing jobs for linuxbridge driver for example, but when the tests start to fail we skip them and finally we stop the job also. To make it clear for operators we add warning logs highlighting that the given feature/driver is experimental, and introduce cfg option to enable such features explicitly." This commit implements this agreement, initially with Linuxbridge Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/845646 [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-April/028164.html Change-Id: Ib18efa3f472736b58c8967847b1061da0e3897d7
* | Merge "ovn: revert to stateful dnat_and_snat"Zuul2022-06-301-0/+8
|\ \
| * | ovn: revert to stateful dnat_and_snatIhar Hrachyshka2022-06-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an effective revert of: I312a950131d62d93fb4bc121bc5e60febb8d35ee "ovn: use stateless NAT rules for FIPs". The performance benefits promised by the "reverted" patch never materialized. On the contrary, the discussion in [1] revealed that the switch to stateless=true made it impossible to fully hw offload nat rules, while it's possible with stateless=false. Specifically, see this comment [2]. Since at this point it's unclear if keeping stateless=true as an option is beneficial for any case, even when w/o hw offload, and to avoid complexity of introducing a config option for unclear benefit, this patch reverts the effects of the original patch, switching all dnat_and_snat objects to implicit stateless=false state. This patch cannot be a clean revert because of the need for db migration. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2004995 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2004995#c18 Change-Id: I9e6e05b7a4f36383a44bd80f07d25052b17bdfa0
* | | Merge "Add a release note for 834162"Zuul2022-06-241-0/+7
|\ \ \
| * | | Add a release note for 834162Damian Dabrowski2022-06-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I forgot to write a release note when pushing change 834162 [1]. It may be an important change for operators so it's good to have a release note about that. [1] https://review.opendev.org/c/openstack/neutron/+/834162 Related-Bug: #1952907 Change-Id: Ie707f461af11357d6eaa004bc98c7eb09a62202f
* | | | Imported Translations from ZanataOpenStack Proposal Bot2022-06-221-2/+36
| |_|/ |/| | | | | | | | | | | | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I831f86460bce279fa140d6171fb5679a4a4e2ece
* | | Merge "[OVN] Add baremetal support without Neutron DHCP agent for IPv4"Zuul2022-06-021-0/+14
|\ \ \ | |_|/ |/| |
| * | [OVN] Add baremetal support without Neutron DHCP agent for IPv4Lucas Alvares Gomes2022-05-251-0/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for deploying baremetal nodes with OVN's built-in DHCP server for IPv4. Since Neutron API's for setting DHCP options is mostly a pass-thru, Ironic uses a dnsmasq syntax for setting the baremetal options [0]. Since this syntax is unlikely to change and it's only a tiny subset of what dnsmasq can offer this patch does translate that syntax used by Ironic and convert it to OVN's equivalent options. In this way we do not need to re-design Neutron's DHCP options API nor change Ironic to use it with ML2/OVN. This option also adds a new configuration option called "disable_ovn_dhcp_for_baremetal_ports". PXE booting nodes can be very sensitive and operators may prefer to use a fully-fledged DHCP server to do it (even Ironic makes DHCP pluggable). So if operators wish to disable OVN's built-in DHCP server for baremetal provisioning they can do so by setting this new option to True. It defaults to False. This change has been tested with real hardware and it does work. That said, we found a problem in core OVN itself [1] while testing it that can affect PXE from reaching the TFTP server, we already communicated this with the core OVN folks and we hope it can be fixed soon. The change in core OVN should not affect the Neutron change tho. Not that the "server-ip-address" DHCP Option now points to the "next_server" option in OVN instead of the "tftp_server_address". The previous behavior was wrong, the "server-ip-address" should set the "siaddr" in the DHCP header and this has been introduced in OVN [2] as an option called "next_server". [0] https://github.com/openstack/ironic/blob/49113385e89c52b56152418d3a0c8c69ddaf8b6e/ironic/common/pxe_utils.py#L523-L538 [1] https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051821.html [2] https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/ Partial-Bug: #1971431 Change-Id: Ia041f640293ba26abf9f70af915817e9861e8ffc Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
* | Merge "[ovn]Refusing to bind port to dead agent"Zuul2022-05-261-0/+4
|\ \ | |/ |/|
| * [ovn]Refusing to bind port to dead agentzhouhenglc2022-05-071-0/+4
| | | | | | | | | | | | Closes-bug: #1958501 Change-Id: Ia84410675d28002afc74368349c9b54f048f4f4d
* | Update python testing as per zed cycle teting runtimeGhanshyam Mann2022-05-111-0/+5
| | | | | | | | | | | | | | | | | | | | In Zed cycle, we have dropped the python 3.6/3.7[1] testing and its support. Add release notes and update the python classifier for the same. [1] https://governance.openstack.org/tc/reference/runtimes/zed.html Change-Id: I8a10b462868f8c015fec3bee5622c41833b06e08
* | Merge "Allow to process FW OF rules belonging to a port in a single operation"Zuul2022-05-101-0/+11
|\ \
| * | Allow to process FW OF rules belonging to a port in a single operationRodolfo Alonso Hernandez2022-05-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new configuration variable to control the OVS OpenFlow rule processing operations: * ``openflow_processed_per_port``: by default "False". If enabled, all OpenFlow rules associated to a port will be processed at once, in one single transaction. If disabled, the flows will be processed in batches of "AGENT_RES_PROCESSING_STEP=100" number of OpenFlow rules. With ``openflow_processed_per_port`` enabled, all Firewall OpenFlow rules related to a port are processed in one transaction (executed in one single command). That ensures the rules are written atomically and apply all of them at the same time. That means all needed rules to handle the ingress and egress traffic of a port using the Open vSwitch Firewall, are committed in the OVS DB at the same time. That will prevent from partially applied OpenFlow sets in the Firewall and inconsistencies when applying new SG rules or during the OVS agent restart. That will override, if needed, the hard limit of "AGENT_RES_PROCESSING_STEP=100" OpenFlow rules that could be processed in OVS at once. If the default configuration values are not modified, the behaviour of the OVS library does not change. Closes-Bug: #1934917 Change-Id: If4984dece266a789d607725f8497f1aac3d73d23
* | | Merge "[OVN] Implement GW IP network QoS inheritance"Zuul2022-05-091-0/+6
|\ \ \ | |_|/ |/| |
| * | [OVN] Implement GW IP network QoS inheritanceRodolfo Alonso Hernandez2022-04-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables the gateway IP network QoS inheritance in the OVN backend driver. The OVN QoS extension will use the router external network (GW network) QoS policy if the gateway IP port has no QoS policy assigned. Partial-Bug: #1950454 Change-Id: I5ee51dc124ae464b9e9fd366cf7bf85176376c25
* | | Remove "live_migration_events" configuration optionRodolfo Alonso Hernandez2022-04-241-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This option was introduced in [1]. This option depended on [2], the Nova code enabling this feature, that filters the "vif-plugged-event" to be sent to Nova. Now the default behaviour is "True". Related-Bug: #1901707 [1]https://review.opendev.org/c/openstack/neutron/+/766277 [2]https://review.opendev.org/c/openstack/nova/+/767368 Change-Id: I05f7e6a7d91f6a4a1fe6d4765589f30257243628
* | | Imported Translations from ZanataOpenStack Proposal Bot2022-04-303-203/+1
| | | | | | | | | | | | | | | | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I6bdf4798864bf82a93cf8e21b153a03210dae256
* | | Merge "ovn migration: Turn validations off by default"Zuul2022-04-251-0/+12
|\ \ \
| * | | ovn migration: Turn validations off by defaultJakub Libosvar2022-03-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The validation is intended mostly for tests and don't make much sense when running the migration in production because likely there are already running workloads. This patch changes the default to False so migration validation must be explicitly asked for. Change-Id: I5470f61a5e0b55bf682526208c3f57dc0ca6ffd5 Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
* | | | Merge "Update port MAC from binding profile for PFs"Zuul2022-04-251-0/+14
|\ \ \ \
| * | | | Update port MAC from binding profile for PFsBalazs Gibizer2022-04-211-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today Nova updates the mac_address of a direct-physical port to reflect the MAC address of the physical device the port is bound to. But this can only be done before the port is bound. However during migration Nova is not able to update the MAC when the port is bound to a different physical device on the destination host. This patch extends port binding logic for direct-physical ports to allow providing the MAC address of the physical device via the binding profile. If it is provided then Neutron overwrites the value of the mac_address field of the port with the value from the active binding profile. Also when the port is being unbound or the MAC address is removed from the active binding porfile then neutron resets the mac_address field of port to a generated MAC to avoid duplicated MAC issues when another port is being bound to the same physical device. The shim API extension for this change is being proposed in I54b4c85ffc4856fba7ad5e9e29f77f74815e1275 in neutron-lib. Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/831935 Closes-Bug: #1942329 Change-Id: Ib0638f5db69cb92daf6932890cb89e83cf84f295
* | | | | Merge "[ovn]Set NB/SB "connection" inactivity probe support multi addresses"Zuul2022-04-251-0/+7
|\ \ \ \ \
| * | | | | [ovn]Set NB/SB "connection" inactivity probe support multi addresseszhouhenglc2022-04-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OVN is clustered, connection be set multiple addresses, inactivity probe cannot currently be set correctly. this patch fix it. Closes-bug: #1958364 Change-Id: I5f83d6f47dc60b849cca5830ec3f77c15a446530
* | | | | | Merge "Remove "allow_overlapping_ips" config option"Zuul2022-04-191-0/+5
|\ \ \ \ \ \ | |_|_|_|/ / |/| | | | |
| * | | | | Remove "allow_overlapping_ips" config optionSlawek Kaplonski2022-04-121-0/+5
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was deprecated in Yoga by patch [1]. Now it's time to remove it. [1] https://review.opendev.org/c/openstack/neutron/+/807848 Closes-Bug: #1942294 Change-Id: I95555395c8adcec70459d5f438e1080da358c4d4
* | | | | Merge "[quota] Enable ``DbQuotaDriverNull`` as a production driver"Zuul2022-04-121-0/+7
|\ \ \ \ \
| * | | | | [quota] Enable ``DbQuotaDriverNull`` as a production driverJakub Libosvar2022-04-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabled ``DbQuotaDriverNull`` as a productio quota database quota driver. This driver does not enforce any quota nor have access to the database. When using this quota driver, the API will return the default empty values expected from the ``QuotaDriverAPI`` class. Closes-bug: #1960032 Change-Id: Iafa24753e657746a8b8165b5a63c17de9a9ba791 Signed-off-by: Jakub Libosvar <libosvar@redhat.com> Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
* | | | | | [docs] L3 router support ndp proxyyangjianfeng2022-04-091-0/+6
| |/ / / / |/| | | | | | | | | | | | | | | | | | | Change-Id: I2b8642b6830d3e1e1ef86c779c55e9ac1d0f7568 Partial-Bug: #1877301
* | | | | [SR-IOV] Default "propagate_uplink_status" flag to TrueRodolfo Alonso Hernandez2022-03-211-0/+7
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extension "uplink-status-propagation" does not allow to modify existing ports. This extension only enables the creation of new ports with this new flag. Similar to [1], this patch changes the default behaviour of the exiting ports: if no "propagate_uplink_status" flag is present, "True" is returned now. The aim of this change is to enable this feature for all existing ports, that is usually the aim of an administrator when enables this extension. [1]https://bugs.launchpad.net/neutron/+bug/1888487 Closes-Bug: #1967881 Related-Bug: #1888487 Change-Id: Ica5b76e0a9a5ae12f764c66be259d7f3cd5b248b
View Lorry Controller Status