I thought we decided that the +k8s:alpha prefix was not needed, but I still see it here. I know the transition to DV is a little complicated (sorry) - am I missing a reason why this needs to stay alpha?

I think it can be removed for ALL of these DV tags since there is no equivalent handwritten logic?

Contrary to e.g. k8s:optional, k8s:immutable hasn't reached the GA stability level - codegen opposed dropping the alpha prefix when I tried to do so.

This also mimics what we had proposed in tosi3k#1.

+k8s:immutable is not yet promoted to stable.

@yongruilin -- I think that resources which are new (alpha), which are not doing new handwritten code, do we still need to do this "it's not stable" dance?

On one hand, the whole apigroup is alpha, so I don't care that the tag is not stable. I don't want to read handwritten code.

On the other hand, we can't let the API go to GA while the tag is still alpha.

Is this the best we can do? It's not terrible since it's 1:1 with a handwritten function, but play it out in the future.

A new API is being built. It needs a new tag. We add a new tag, but it is not stable. Does this mean we have to write handwritten code for the new tag-equivalent? That doesn't seem to mitigate any risk, which is why we need pre-stable tags in the first place.

How could we avoid needing new handwritten?

Under current implementation, we can add // +k8s:validation-gen-nolint to the new type to bypass the lint check for this new API type. So that we can benefit from the pre-stable tags. And in the following release, when API is ready for GA, we should be able to promote the pre-stable tags to stable while dropping the validation-gen-nolint.

Bringing back a lost comment:

Given the discussion around the meaning of required WRT openapi vs. k8s, perhaps this should ALSO specify minItems=1. Right now "required" implies that, but openapi would allow podGroupTemplates=[] (since that satisfies openapi "required"). We don't actually have a minItems tag yet, but it's trivial to add and when we do it would apply to this.

@lalitc375 what do you think? Worthwhile or redundant?

Lalit is OOO until next Monday, unfortunately :(

If this ends up as the last comment, it could be a followup.

#137587

Why no DV tags for this? +k8s:listType=map etc

Is it because we still need to manually call the ValidateConditions(), which causes dup errors? If so, maybe a comment here?

Is it because we still need to manually call the ValidateConditions(), which causes dup errors?

Exactly.

If so, maybe a comment here?

Hmm, on one hand I agree such comment would bring about more clarity, on the other hand:

• IIUC it's preferable to have matching comments in the internal and the external API definitions - and we don't use the DV tags in the internal type definitions, so having that comment in the internal type would be confusing.
• Other APIs that use metav1.Condition in their status do not document that either - so it's more of a systemic problem rather than the problem with this particular API.

Would an appropriate comment in pkg/apis/scheduling/validation/validation.go instead (above the line where we use metav1validation.ValidateConditions) make more sense?

It's only a "problem" in that adding DV to metav1.Condition would generate DV for ~every type, which is only a "problem" because we haven't spent time to fix that :)

@aaron-prindle @yongruilin @lalitc375

Gut-check time: What if we actually started enabling deeper DV? When will we feel comfortable doing this?