Elemental is an immutable Linux distribution built to run Rancher and its corresponding Kubernetes distributions RKE2 and k3s. It is built using the Elemental-toolkit
This epic is to define how and if we should mutate Declarative Networking on live systems.
For example to "switch a running node to a different (time-, name-, gateway-)server".
This is technically possible by manually editing the network config on a single MachineInventory for example, and using an annotation or any kind of trigger to tell the elemental-register to apply the new network config on the running system. (A pre-requisite would be https://github.com/rancher/elemental-operator/issues/806 to be able to modify the network applicator yip config)
However, the scenario is still unclear. We miss input on why the node config needs to change (modifying a route for example?), and possibly some analysis on the impact of such feature, since it can break many things with no chances of recovery.
The best recommendation we have at the moment is to rely on the Elemental Reset workflow to apply any kind of change to machines. This not only will ensure that Machines will have immutable and reproducible configurations, but it will also confine any kind of configuration change to an explicit phase (reset), so that it will be easier to implement fallback/recovery automatic behaviors in case things go wrong.
This epic is to define how and if we should mutate Declarative Networking on live systems.
For example to "switch a running node to a different (time-, name-, gateway-)server".
This is technically possible by manually editing the network config on a single MachineInventory for example, and using an annotation or any kind of trigger to tell the
elemental-register
to apply the new network config on the running system. (A pre-requisite would be https://github.com/rancher/elemental-operator/issues/806 to be able to modify the network applicator yip config)However, the scenario is still unclear. We miss input on why the node config needs to change (modifying a route for example?), and possibly some analysis on the impact of such feature, since it can break many things with no chances of recovery.
The best recommendation we have at the moment is to rely on the Elemental Reset workflow to apply any kind of change to machines. This not only will ensure that Machines will have immutable and reproducible configurations, but it will also confine any kind of configuration change to an explicit phase (reset), so that it will be easier to implement fallback/recovery automatic behaviors in case things go wrong.