Backport of arbitrary custom clevis pin in ignition spec 3.5 #2196
Conversation
alicefr
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.
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. Signed-off-by: Alice Frosi <afrosi@redhat.com>
alicefr
force-pushed
the
backport-clevis-3-5
branch
from
116bfcc to
23ff227
Compare
|
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. |
|
@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? |
|
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 |
2 participants
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.