[v1beta2] Improve `AdditionalUserData` API

[anmazzotti]

The current definition of additionalUserData in RKE2ControlPlane and RKE2Config has two main issues:

1. additionalUserData.config (Ignition) and additionalUserData.data (cloud-init) have different types (string vs map[string]string) and implementation
2. both implementations (string and map[string]string) are sub-optimal to represent a schemaless nested object, but of the two, map[string]string is absolutely the most confusing and hard to work with (see cloud-init arbitraryTemplate handling)

The most appropriate and straightforward implementation would be map[string]runtime.RawExtension, like this example. This can support cloud-init and ignition equally, with a better user experience and simpler deserialization and (strict: true) validation (no more template complexity):

Old

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: cloud-init
spec:
  agentConfig:
    format: cloud-init
    additionalUserData:
      strict: true
      data:
        bootcmd: |
          - touch /foo.bar
          - touch /bar.foo
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: ignition
spec:
  agentConfig:
    format: ignition
    additionalUserData:
      strict: true
      config: |
        storage:
          luks:
            - name: data
              device: /dev/disk/by-partlabel/USR-B

New

apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
  name: cloud-init
spec:
  agentConfig:
    format: cloud-init
    additionalUserData:
      strict: true
      cloudConfig:
        bootcmd:
          - touch /foo.bar
          - touch /bar.foo
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
  name: ignition
spec:
  agentConfig:
    format: ignition
    additionalUserData:
      strict: true
      cloudConfig:
        storage:
          luks:
            - name: data
              device: /dev/disk/by-partlabel/USR-B

The new cloudConfig key is just a quick suggestion to have 1 seamless definition, instead of unnecessarily splitting between config and data, since the user can already configure the format field.
Warning: API conversion is going to be the biggest challenge of this issue.

[valaparthvi]

The current cloud-init arbitrary data handling or more specifically cleanupArbitraryData() also has formatting issue.
For e.g.

bootcmd:
- echo 192.168.1.130 us.archive.ubuntu.com > /etc/hosts
- [cloud-init-per, once, mymkfs, mkfs, /dev/vdb]

is formatted to the following after cleanup:

## template: jinja
#cloud-config

bootcmd: 
- echo 192.168.1.130 us.archive.ubuntu.com > /etc/hosts
- - cloud-init-per
  - once
  - mymkfs
  - mkfs
  - /dev/vdb

The data should be copied as it is in the secret/cloud-init file.

[anmazzotti]

Actually, a big misunderstanding on my side is that additionalUserData.config can also be used for cloud-init format.
So additionalUserData.config and additionalUserData.data only seem to differ in format string vs map[string]string.

Can additionalUserData.data simply be deprecated? The string format is also suitable and doesn't need to be changed I believe, just the user has to make sure it's valid yaml.

Edit: @valaparthvi pointed out #167 as the origin of the data format, so there is a use case to implement something different than string, it just shouldn't be map[string]string and it should cover both ignition and cloud-init seamlessly. Then maybe config can be deprecated instead.

[github-actions]

This issue is stale because it has been open 90 days with no activity.

[github-actions]

This issue is stale because it has been open 90 days with no activity.