Ignition templating

[xsen84]

Summary

Add functionality to the metal-operator to process and manage the generation of ignition secrets for ServerClaim objects. This feature will ensure that ignition secrets are derived from ignition templates and filled in with values computed by various ignition providers (e.g., networking, storage). The status of the ServerClaim will reflect the readiness state of the operation for each ignition provider.

Example workflow for the feature:

1. A ServerClaim object is created:

ServerClaim:

apiVersion: metal.ironcore.dev/v1alpha1
kind: ServerClaim
metadata:
  name: somehostname-claim
spec:
  serverRef:
    name: somehostname-server
  serverSelector:
    cpu: 100
  ignitionProviders:
    - name: someprovider-networking
      spec:
        foo: bar
    - name: someprovider-storage
      spec:
        bar: foo
  ignitionRef:
    name: somehostname-ignition
  ignitionTemplateRef:
    name: someignition-template

2. The specified ignition template someignition-template will contain place holders to be updated, by operator, with the computed values from the ignition providers.

3. Ignition providers (e.g., someprovider-networking and someprovider-storage) will compute their values and update the valuesConfigRef.

4. Each controller will update the ServerClaim status to show the readiness state of each provider:

status:
  ignitionProviders:
    - name: someprovider-networking
      state: Ready
      valuesConfigRef:
        name: someprovider-networking-values
    - name: someprovider-storage
      state: Pending
  status: Bound

5. the operator will merge/inject the computed values into the ignition template and create the an ignition secret. Also set the ServerClaim annotation to reflect the readiness state of the operation.

Motivation

Streamline the process of generating ignition secrets for ServerClaim objects by dynamically populating values from ignition providers.

[afritzler]

A few comments:

1. General question: Should the provider config be fulfilled by an external operator or is this a build in feature of the metal-operator?

2. How should the ignitionProviders slice look like? Should we have a ProviderConfig type which looks like the following?

type ProviderConfig struct {
   name string
   config *runtime.RawExtension
}

In the case of an external operator we can't import the spec of the provider specific type.

3. Do we expect an IgnitionTemplate + provider config being present which are then being rendered and a Secret is being created + the ServerClaim.Spec.IgnitionRef being mutated to ref this Secret?

4. Is the IgnitionTemplate the same for all Providers?

[Nuckal777]

General question: Should the provider config be fulfilled by an external operator or is this a build in feature of the metal-operator?
How should the ignitionProviders slice look like? Should we have a ProviderConfig type which looks like the following?

I think these should be dedicated controllers, so a separation is possible. We can consider providing some bundled for shared concerns in the metal-operator though. This would also imply the runtime.RawExtension stuff in case an external controller is supposed to provider some values.

Do we expect an IgnitionTemplate + provider config being present which are then being rendered and a Secret is being created + the ServerClaim.Spec.IgnitionRef being mutated to ref this Secret?

Sounds good to me.

Is the IgnitionTemplate the same for all Providers?

I think this meant to hold a golang template string. The content will differ between the chosen providers, because the values available for templating will depend on the given provider configs.