From c90425fbfd1f9d51c14060cc96a3792ccaf1e950 Mon Sep 17 00:00:00 2001 From: Jan Horstmann Date: Mon, 17 Feb 2025 13:32:32 +0100 Subject: [PATCH] Add operations docs for applying network changes Part of https://github.com/osism/issues/issues/1214 Part of https://github.com/osism/issues/issues/1215 Signed-off-by: Jan Horstmann --- docs/guides/operations-guide/network.md | 38 +++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/docs/guides/operations-guide/network.md b/docs/guides/operations-guide/network.md index d2af3177e9..cb7d16ec69 100644 --- a/docs/guides/operations-guide/network.md +++ b/docs/guides/operations-guide/network.md @@ -4,6 +4,44 @@ sidebar_label: Network # Network +## Modifying the network configuration + +While the network layout of a production environment is mostly static, +sometimes it is necessary to make changes. There is however no guarantee that +the transition from one network configuration state to the next does not cause +interruptions to existing network flows. E.g. even very short down/up cycles of +interfaces may cause additional disturbances to SDN networks in upper layers, +which are not reconciled immediately or never at all. +Therefore it is required to move any existing payload when modifying the +network configuration of compute nodes. You may use the +[OpenStack Resource Manager](./tools/resource-manager#live-migration) +to achieve this, e.g.: + +``` +osism manage compute migrate $COMPUTE_NODE +``` + +Applying the network change is then limited to the empty compute node, e.g.: + +``` +osism apply network --limit $COMPUTE_NODE +``` + +While it is possible to make the changes effective immediately by appending +`--extra-vars network_allow_service_restart=true` to the command above, it is +recommended to make changes effective through restart of the node. The reason +for this is that some changes, like e.g. removal of an interface from +configuration, will not necessarily lead to it being removed, but just to it +being unmanaged. A reboot will ensure that only the actually defined network +configuration will be set up. You may use `osism` to reboot the node and wait +for it to come back up: + +``` +osism apply reboot --limit $COMPUTE_NODE --extra-vars reboot_wait=true --extra-vars ireallymeanit=yes +``` + +## Internal components + OpenStack, OVN, and Open vSwitch all really like UUIDs. ```