-
Notifications
You must be signed in to change notification settings - Fork 107
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
providers/vmware: Process guestinfo.metadata netplan configuration
The network environment can be dynamic and thus needs to be provided as VM metadata. Since the format should not depend on whether the VM runs uses Ignition and Afterburn or Cloud-Init, the idea is to also support the guestinfo.metadata variable as used by Cloud-Init which contains Netplan YAML/JSON network configuration. Add a new command to write out netplan configs to a given directory, similar as we do with networkd units. While this is currently just used for VMware, other providers could also construct the netplan data type to provide netplan configurations if the OS rather wants to use NetworkManager than systemd-networkd. For backwards compatibility and to not need netplan it would be nice to keep the systemd-networkd support as long as its used. References: https://cloudinit.readthedocs.io/en/latest/reference/datasources/vmware.html#walkthrough-of-guestinfo-keys-transport https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v2.html https://netplan.io/reference/ https://linux-on-z.blogspot.com/p/using-netplan-on-ibm-z.html
- Loading branch information
Showing
11 changed files
with
330 additions
and
11 deletions.
There are no files selected for viewing
This file contains 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
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains 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 file contains 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 file contains 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 file contains 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 file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
--- | ||
nav_order: 2 | ||
parent: Usage | ||
--- | ||
|
||
# VMware Netplan guestinfo metadata | ||
|
||
The network environment can vary between VMware servers and instead of leaking these requirements into userdata snippets, a well-known guestinfo metadata field can be used. | ||
The guestinfo metadata field is OS-independent and supported by cloud-init and afterburn. It requires Netplan to render the Netplan YAML format to either NetworkManager or systemd-networkd configuration files. | ||
By default, systemd-networkd units are used. Since the renderer backend is defined in the Netplan config itself, requiring NetworkManager would rule out support for systems that don't use it (unless they would postprocess the `renderer` field to force it to `networkd`). Since systemd-networkd can work in parallel with NetworkManager, it's expected that the renderer field is left to its default. | ||
|
||
The afterburn invocation is as follows, where `FOLDER` could be `/run/netplan/`: | ||
|
||
``` | ||
afterburn multi --netplan-configs FOLDER --provider vmware | ||
``` | ||
|
||
Afterwards, `netplan generate` can be used to render the config files. If that is done before `systemd-networkd` runs, this is enough, but if the network already is up, `netplan apply` should be used instead. | ||
|
||
## Specifying the guestinfo metadata | ||
|
||
The guestinfo keys are named `guestinfo.metadata` for the content and `guestinfo.metadata.encoding` to specify the encoding of the content. | ||
The value of the encoding field can be empty to indicate raw string data, or one of `base64` or `b64` to indicate an base64 encoding, or one of `gzip+base64` or `gz+b64` to indicate base64-encoded gzip data. | ||
|
||
An example for raw string data is the following: | ||
``` | ||
network: | ||
version: 2 | ||
ethernets: | ||
nics: | ||
match: | ||
name: ens* | ||
dhcp4: yes | ||
``` | ||
|
||
The supported config format with examples can be found in the [Netplan specification](https://netplan.readthedocs.io/en/latest/netplan-yaml/). |
This file contains 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 file contains 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
Oops, something went wrong.