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.
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.