Config variables mapping to and from machine registration crd

[davidcassany]

the machine registration crd spec is what ends up populating the config.Config struct in elemental-operator, when registering and fetching all the data it looks like the data we retrieve does not match config.Config variable names. It is unclear to me how this marshal and unmarshal process works, but I am pretty convinced we have some divergences in there.

I also bet this could be related to #46 as we already have a noSMBIOS variable inside config.Config.Elemental.Registration.

[fgiudici]

Elemental Install data addressed in #64

[davidcassany]

@fgiudici I think we need to include yaml labels everywhere, I found more inconsistencies on registration and system agent structs. I think I finally understood why it is not failing even being inconsistent.

Note that manually writing a machineregistration.yaml to kubectl apply requires the json labels, however elemental-operator produces yaml files when fetching data (does not follow json labels), then elemental-operator register reads yaml files (again it does not follow the json labels). Since elemental-operator produces and reads yaml files for the registration process it simply works even being inconsistent.

Take the example of the system_agent as an example:

1. After loading a machine registration what you get from kubectl get -n fleet-default machineregistrations.elemental.cattle.io test-nodes -o yaml follows the json labels, so there is config.elemental.system_agent
2. What you get from curl -k <registrationURL> does not follow the json labels, so there is config.elemental.systemagent
3. What elemental-operator register reads are yamls and does not follow the json labels, since the files we are reading here were created on step 2 it is consistent. Even kubectl get will show a different syntax 😱

It all works fine since the fields we are actually including manually in a machine registration yaml are all part of the install or cloud-config and these are already including yaml and json labels.

This setup works, but is ugly as hell and as it all depends on our side I strongly believe we should add yaml labels everywhere in addition to the json ones.

Also it is the right time to apply some criteria and decide if, for instance, we want cacert, ca_cert, caCert or ca-cert. I have preference to ca-cert and no-smbios to match the flags syntax, but no strong opinion.

[davidcassany]

Also adding the yaml labels with the omitempty will make the result of curl -k <registrationURL> to omit all empty data and then the result will look like the following:

elemental:
  registration:
    url: https://ranchersuse/elemental/registration/kjd7q4nbf8kkb9slvlbchxt45p676dj67ll8bb5x5b4pc57dl5fkzq
    cacert: |-
      -----BEGIN CERTIFICATE-----
      MIIBpzCCAU2gAwIBAgIBADAKBggqhkjOPQQDAjA7MRwwGgYDVQQKExNkeW5hbWlj
      bGlzdGVuZXItb3JnMRswGQYDVQQDExJkeW5hbWljbGlzdGVuZXItY2EwHhcNMjIw
      NzE0MDgzMTM3WhcNMzIwNzExMDgzMTM3WjA7MRwwGgYDVQQKExNkeW5hbWljbGlz
      dGVuZXItb3JnMRswGQYDVQQDExJkeW5hbWljbGlzdGVuZXItY2EwWTATBgcqhkjO
      PQIBBggqhkjOPQMBBwNCAARALzVe/qVHEhX4doODreuKydYKvLHRTJ+eG85jIimV
      VN001MshCh3KusuYBuGH8GSY+Zz4ieJDICEnBOrdCVp2o0IwQDAOBgNVHQ8BAf8E
      BAMCAqQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUa+46+mWZVkp/r/S9wZdo
      KS7ZNsswCgYIKoZIzj0EAwIDSAAwRQIhAMKAV3P9mLAu0Esrcg0iDUq+Q46+H4/r
      XXseh20+NnXHAiABBrj0T6CiLScUxxRr3m9ciP4bIHDKQPMJPRtOJIK9BA==
      -----END CERTIFICATE-----

IMHO way nicer

[fgiudici]

Yep, thanks @davidcassany . Agree on all these, will take care of it 👍🏼