/cc @jiahuif

/milestone v1.24
/priority critical-urgent

@dims: The provided milestone is not valid for this repository. Milestones in this repository: [next-candidate, v1.16, v1.17, v1.18, v1.19, v1.20, v1.21, v1.22, v1.23, v1.24, v1.25, v1.26]

Use /milestone clear to clear the milestone.

/cc @leilajal
/triage accepted

Changes for 1.24 are merged, lowering priority and removing from milestone

This still needs to be addressed in the KEP and coordinated with generated clients before the feature hits GA and our static snapshot unconditionally contains enum info

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

/triage accepted
/cc @jiahuif Just to make sure you are aware of this one^^

Discussed this with Alex. Enum is not a type here, the type is still string, int, or whatever. Clients should accept values that they don't know about since they might not know about the most recent versions. We need to work with client generators so that they don't generate enums that can't be be extended.

My plan is to create a CLI tool to remove enum tags from openapi specs for generated clients. The trade-off is that such clients are not aware of the enums in any way unless they fetch the schema from the api server and parse themselves. How do you think of it? @apelisse

I think that's wrong. It's not that clients shouldn't be aware of enums, they should be doing the right thing. They have plenty of options.

If I was building a rust client, I would generate the following:

enum Color {
    Red,
    Blue,
    Green,
    Unknown(color),
}

And clients should be able to generate such a thing.

Because client generation uses standard OpenAPI client generator for each language, and there does not seem to be a "enum mode" switch, I guess the plan would be hack the generator for each language.

Because client generation uses standard OpenAPI client generator for each language, and there does not seem to be a "enum mode" switch, I guess the plan would be hack the generator for each language.

😞 . You're right. Then yeah, maybe a tool to filter out the enum is the right way to go, though another option might be to talk to some of these standard openapi client generator to see if we can make that work? I still think it's a little weird to block any updates to enums.