You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ignition is currently one big file which holds several distinct parts of config at least:
OS Config
Network Config
Kubernetes Config
I would want to expose these parts towards the different teams that need to provide input in a clean API.
Basic example
As a gardener operator i only write the ignition which adds the node to the cluster.
As a network operator i only write the ignition which enables the node to interact with the fabric.
As a ceph operator i can write an ignition which configures OS kernel settings towards the ceph use case.
As a kvm operator i can write an ignition which configures OS kernel settings towards the hypervisor case.
Motivation
We do not need to manage a huge ignition which can hold even conflicting information from different sources.
The text was updated successfully, but these errors were encountered:
Summary
The ignition is currently one big file which holds several distinct parts of config at least:
I would want to expose these parts towards the different teams that need to provide input in a clean API.
Basic example
As a gardener operator i only write the ignition which adds the node to the cluster.
As a network operator i only write the ignition which enables the node to interact with the fabric.
As a ceph operator i can write an ignition which configures OS kernel settings towards the ceph use case.
As a kvm operator i can write an ignition which configures OS kernel settings towards the hypervisor case.
Motivation
We do not need to manage a huge ignition which can hold even conflicting information from different sources.
The text was updated successfully, but these errors were encountered: