Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add operations docs for applying network changes #796

Merged
merged 1 commit into from
Feb 17, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions docs/guides/operations-guide/network.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,43 @@ 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 `osism` command
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.

```
Expand Down
Loading