v33tov32: fix 3.3 -> 3.2 Clevis pointer translation

[jkyros]

Per openshift/machine-config-operator#3576 (comment), Clevis was a pointer in 3.2, but isn't in 3.3, so down-translation from 3.3 -> 3.2 resulted in a panic.

I also added a test here, but I can retool it or drop it.

I was going to add a test for Clevis.Custom also, but it looks like pin is simultaneously required and and an error if supplied, so I gave up? I'm probably missing...something 😄 :

https://github.com/coreos/ignition/blob/0680c483fce356c3ddd2bcec913f41e847adc51e/config/v3_2/types/custom.go#L28
https://github.com/coreos/ignition/blob/0680c483fce356c3ddd2bcec913f41e847adc51e/config/v3_3/types/clevis.go#L36

/cc @prestist

[prestist]

Thank you for doing this, and I take a look and see what all the fuss is about.

[prestist]

Added a basic ClevisCustom test that does enforce your changes and I was shocked to see no other tests that cover it in the test file.

[prestist]

I am currently pondering how to move this change to be more of an after the fact effect like the rest of the checks. TBC this change does work, and catches / fixes the issue. However, typically that section is really a copy and paste from the ignition repo and I would like to keep that true, though I am not sure what to do about that.

@bgilbert I wonder if you have any insight?

[bgilbert]

Thanks for doing this!

Do we need a similar change for Link.Target?

I was going to add a test for Clevis.Custom also, but it looks like pin is simultaneously required and and an error if supplied, so I gave up?

The pin is required if the config is present. Where are you seeing that it can't be supplied? Both of the code snippets you posted require it.

I am currently pondering how to move this change to be more of an after the fact effect like the rest of the checks. TBC this change does work, and catches / fixes the issue. However, typically that section is really a copy and paste from the ignition repo and I would like to keep that true, though I am not sure what to do about that.

I don't see a straightforward way to do that, and wouldn't worry about it. The converter code doesn't need to be super-clean, and the switch from pointers to embedded structs is a one-off change that won't happen again. (Ignition now has unit tests to make sure we don't get more struct pointers in the future.) Let's just make sure we update the leading comment block to indicate what changes were made to the original translation code.

[prestist]

@bgilbert I updated the comment to include some details about the change that breaks the pattern, and we don't need to do anything with the link.target, it looks like the other direction was accounted for previously.