Backport of arbitrary custom clevis pin in ignition spec 3.5

[alicefr]

The original PR is #2145.

In order to support new clevis pin, either they need to be added each time in the hardcoded list of pins or ignition can allow any name for the pin. This is required in order to enable the clevis trustee pin used for confidential clusters.

The backport to 3.5 is necessary because the rust crate for ignition only support up to 3.5 config version and cannot be used with 3.6-experimental.

[alicefr]

/cc @prestist @travier

[gemini-code-assist]

Code Review

This pull request backports the functionality to allow arbitrary custom clevis pins to version 3.5 of the configuration. The change correctly removes the validation that restricted the pin to a hardcoded list of values, which is necessary to support new pin types like trustee. The corresponding test has been updated to reflect this change. The implementation is correct and achieves the stated goal.

[prestist]

hmm, while this is significantly easier.. should we not be stabilizing 3.6? is there any risk in this going to a stable version of ignition config?

I expect confusion, and misunderstandings.

[alicefr]

@prestist I did the backport because it isn't really an api change but we are relaxing the check and list of the pin. How long would it take to stabilize 3.6 in your opinion? And eventually what need to be stabilize?

[prestist]

I can definitely see why you would want to backport that support... and this does feeel like we can do that for this however; in doing this It means 3.5 behaves differently on different versions of ignition. Which will confuse the user and make one ignition config work on a system as expected but not as expected on another. Even though they both support 3.5.

The main thing is any direct change to the contract, rather implicit or explicit once stabilized can break trust. Warnings are about as far as we go, even if a bug existed in the past we would add a warning on stable versions fixing in exp ones. I am welcome to push back here but would like more people to push back before going down the route of updating functional change on a stabilized version.

Stabilization is a more time involved process for sure, it would likely take a sprint or so. You can see the checklist here => #1925

@travier

[alicefr]

@prestist if we can make 3.6 stable, I'm fine with it. I was worried to graduate from experimental, it was taking longer

[prestist]

Im not sure we really have much of a choice.

What timeline do you need? I can create a card and plan for it next sprint?

[cverna]

I would love to see if we can get OpenCode or other agent execute that stabilization checklist. It feels like it could be a great win if the get even 80% done by an agent.

[alicefr]

Im not sure we really have much of a choice.

What timeline do you need? I can create a card and plan for it next sprint?

Ideally, if we could target it for openshift 4.22, which would be June this year. Otherwise, the Red Hat CoreOS node needs to use the experimental 3.6.