Backport Gateway_Chassis to HA_Chassis_Group migration #225
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This new command allows to create a "HA_Chassis_Group" register and the corresponding "HA_Chassis" child registers. If the parent "HA_Chassis_Group" register already exists, it allows to update the priority of the "HA_Chassis" registers or deleting the discarded ones. Partial-Bug: #2092271 Change-Id: I73ed014ae6a36e171c1eace8bea45010cf8415fa Conflicts: neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/commands.py
This method returns the name of the chassis assigned in the "HA_Chassis_Group" associated with the "Logical_Router_Port", ordered by the priority. Partial-Bug: #2092271 Change-Id: Ifbecf0f2699297a85e67299ce6d8ec98fd41fae4 Conflicts: neutron/common/ovn/utils.py
Partial-Bug: #2092271 Change-Id: Iafd1edcda72720bcd185d9d232de8e8e03a7cbff
Added a new method in ``OvsdbNbOvnIdl`` to retrieve the gateway ``Logical_Router_Port`` chassis list with priorities, stored in the ``HA_Chassis_Group`` register associated to the router. Partial-Bug: #2092271 Change-Id: I6b2bc7a3e80a906f146da3645c530d175f31a8dd
Now is possible to set a ``HA_Chassis_Group`` in a ``Logical_Router_Port``, using the NB API methods ``add_lrouter_port`` and ``update_lrouter_port``. Both methods support creating the ``HA_Chassis_Group`` in the same transation the LRP is created or updated. Partial-Bug: #2092271 Change-Id: Iab7581d2f4eff8ab84a2a379499490353fbe1971
The new maintenance method ``migrate_lrp_gateway_chassis_to_ha_chassis_group``, replaces the ``Logical_Router_Port`` ``Gateway_Chassis`` with the equivalent ``HA_Chassis_Group``, that is the preferred method for HA scheduling in OVN, as reported in the LP bug. Partial-Bug: #2092271 Signed-off-by: Rodolfo Alonso Hernandez <[email protected]> Change-Id: I8994415f97bca575b7104824ef889da0235c9a8b
TODO: * Testing NOTE: this method cannot be merged alone, it would need ``schedule_unhosted_gateways`` too and a migration strategy (a maintenance method) The NB API method ``schedule_new_gateway`` now creates a ``HA_Chassis_Group`` and its ``HA_Chassis`` registers, and associates it to the gateway ``Logical_Router_Port``. The usage og ``Gateway_Chassis`` is deprecated. Partial-Bug: #2092271 Change-Id: If38f405428a8b27bf551db48c4e96d75deeb09fc Signed-off-by: Rodolfo Alonso Hernandez <[email protected]>
When creating a network and adding a port, the API requests will often be handled by different workers. Since each worker maintains its own internal copy of the OVN DBs, it is possible that the request for creating the port arrives at a worker that has not yet received notification that the Logical Switch for the network has been created. When the code for adding the Logical Switch Port is called, it tries to look up the LS, and fails. Currently, a retry-and-wait solution is in place for the LS/LSP issue in create_port(), but a new feature introduced in OVS 3.1 allows specifying the UUID of the LS, so that we can use a value known to the other worker, and add the LSP to the LS by that UUID even if the LS isn't in our local DB cache. This allows the ovsdb-server to be the source of truth on the existance of the LS. There are lots of other interactions that could result in this kind of race condition, any create/update of objects that happen rapidly on systems under high load for example. This method of creating and referencing objects should be generalizable. In this patch, the UUID for the LS is defined as the UUID for the neutron network. The name of the LS continues to be neutron-$UUID to match existing usage and to keep lookups by name working. Change-Id: Icc27c2b8825d7f96c9dac87dec8bbb55d493d942
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.