Modify network configuration on an existing machine¶

TechPreview

Caution

For MKE clusters that are part of MOSK infrastructure, the feature is not supported yet.

Modification of network configuration of an existing machine requires a separate approval step from the Infrastructure Operator. This validation is required to prevent accidental cluster failures due to misconfiguration.

While making approval decisions, the Operator verifies the result of network configuration changes per host using the fields located in the IpamHost object status.

For more details, see IpamHost status.

To modify network configuration on an existing machine:

Edit the L2 template as required.
Verify the statuses of the IpamHost objects that use the L2 template being updated:
```
kubectl get IpamHost <ipamHostName> -o=jsonpath-as-json=\"{.status['netconfigCandidate','netconfigCandidateState','netconfigFilesStates','messages']}\"
```
Caution

The following fields of the ipamHost status are renamed since Container Cloud 2.22.0 in the scope of the L2Template and IpamHost objects refactoring:
- netconfigV2 to netconfigCandidate
- netconfigV2state to netconfigCandidateState
- netconfigFilesState to netconfigFilesStates (per file)
No user actions are required after renaming.

The format of netconfigFilesState changed after renaming. The netconfigFilesStates field contains a dictionary of statuses of network configuration files stored in netconfigFiles. The dictionary contains the keys that are file paths and values that have the same meaning for each file that netconfigFilesState had:
- For a successfully rendered configuration file: OK: <timestamp> <sha256-hash-of-rendered-file>, where a timestamp is in the RFC 3339 format.
- For a failed rendering: ERR: <error-message>.
- If the configuration is valid:
  - The netconfigCandidate field contains the Netplan configuration file candidate rendered using the modified L2 template
  - The netconfigCandidateState and netconfigFilesStates fields have the OK status
  - The netconfigFilesStates field contains the old checksum meaning that the effective Netplan configuration is still based on the old version of the L2 template
  - The messages field may contain some warnings but no errors
- If the L2 template rendering fails, the candidate of Netplan configuration is empty and its netconfigV2state status contains an error message. A broken candidate of Netplan configuration cannot be approved and copied to the effective Netplan configuration.
Warning

Do not proceed to the next step until you make sure that the netconfigV2 field contains the required configuration and this configuration is valid.
Approve the new network configuration for the related IpamHost objects:
```
kubectl patch IpamHost <ipamHostName> --type='merge' -p "{\"spec\":{\"netconfigUpdateAllow\":true}}"
```
Once applied, new settings are copied to the effective Netplan configuration and sent to the corresponding nodes by the LCM Controller.
Verify the statuses of the updated IpamHost objects:
```
kubectl get IpamHost <ipamHostName> -o=jsonpath-as-json=\"{.status['netconfigCandidate','netconfigCandidateState','netconfigFilesStates','messages']}\"
```
Caution

The following fields of the ipamHost status are renamed since Container Cloud 2.22.0 in the scope of the L2Template and IpamHost objects refactoring:
- netconfigV2 to netconfigCandidate
- netconfigV2state to netconfigCandidateState
- netconfigFilesState to netconfigFilesStates (per file)
No user actions are required after renaming.

The format of netconfigFilesState changed after renaming. The netconfigFilesStates field contains a dictionary of statuses of network configuration files stored in netconfigFiles. The dictionary contains the keys that are file paths and values that have the same meaning for each file that netconfigFilesState had:
- For a successfully rendered configuration file: OK: <timestamp> <sha256-hash-of-rendered-file>, where a timestamp is in the RFC 3339 format.
- For a failed rendering: ERR: <error-message>.
The new configuration is copied to the effective Netplan configuration and both configurations are valid when:
- The netconfigCandidateState and netconfigFilesStates fields have the OK status and the same checksum
- The messages list does not contain any errors