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
This issue is about applying Bootstrap configs into Elemental hosts.
Within CAPI, any Bootstrap provider will create a bootstrap secret containing two fields: format and value.
According to the CAPI documentation, cloud-init is the default engine, however ignition is also an option.
Ideally Elemental will support both, and the architecture should easily allow the support of new engines, if any will arise.
Also note that from a functional perspective, Elemental must allow end users to apply "plans" into host machines.
In the current elemental-operator this can be done by updating the remote secrets watched by the system-agent.
In CAPI context, the same mechanism used to bootstrap a host, can be exposed to end users to apply additional configurations.
For this purpose we do have few options and we should make a decision:
Rely on the Rancher's system-agent, mapping cloud-init configs into local plans through the Elemental agent, or by configuring the Rancher's system-agent to watch remote secrets.
Rely on the elemental-toolkit. It's capable of applying cloud-init configs already.
Let the new Elemental agent take care of directly applying cloud-init configs.
???
Also note that none of the proposed solutions seem to cover the ntp cloud-init command that the RKE2 provider is using, so additional support should be implemented for that.
The text was updated successfully, but these errors were encountered:
This issue is about applying Bootstrap configs into Elemental hosts.
Within CAPI, any Bootstrap provider will create a bootstrap secret containing two fields:
format
andvalue
.According to the CAPI documentation,
cloud-init
is the default engine, howeverignition
is also an option.Ideally Elemental will support both, and the architecture should easily allow the support of new engines, if any will arise.
Also note that from a functional perspective, Elemental must allow end users to apply "plans" into host machines.
In the current
elemental-operator
this can be done by updating the remote secrets watched by the system-agent.In CAPI context, the same mechanism used to bootstrap a host, can be exposed to end users to apply additional configurations.
For this purpose we do have few options and we should make a decision:
elemental-toolkit
. It's capable of applying cloud-init configs already.Also note that none of the proposed solutions seem to cover the
ntp
cloud-init command that the RKE2 provider is using, so additional support should be implemented for that.The text was updated successfully, but these errors were encountered: