canonical / canonical/microcloud
Ambiguous underlay network handling with `microcloud add`
- Dominant language
- Go
- Stars
- 532
- Forks
- 83
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 36
Description
When setting up a cluster with `microcloud init`, and setting up OVN, we ask if the user wants to set up underlay networking. MicroOVN accepts configuration for each system over its API and applies it when initializing the system.
During `microcloud add` (and `microcloud service add`), we again offer the user to set up underlay networking, but which systems to set the networking up on cannot be easily determined.
Ideally, if the user previously did not configure underlay networking, we should let them configure it now that they are adding new systems. But that involves both fetching the existing configuration and applying it over the API on a running system.
MicroOVN does not have API support to fetch the existing underlay configuration, nor does it support setting the underlay configuration over the API after bootstrap/join.
We can't even really be conservative and only allow setting up new systems because if the user previously skipped setup, then not all systems will have an underlay network set.
So there's 2 parts to this:
* We need a way to _get_ the current underlay network configuration for the cluster. If we only have this, then we can check the existing cluster configuration and only present a table if a configuration exists. This table would be limited to just the new systems. This means we wouldn't be able to introduce underlay networking if it was not set up before running `microcloud add`.
* Also add a way to _set_ the underlay network configuration of existing systems. With this, we can inspect old systems and include them in the configuration if underlay networking was initially skipped. This is the same behaviour as storage pool, osd, and uplink network configuration.
LXD-1443
Contributor guide
Assessment
This issue has not been assessed yet.