Docs could use clarity regarding nested support levels

[gcs278]

What happened: Pardon me if I'm missing something, but it seems like the docs could use clarity regarding nested support levels. The main scenario that is causing confusion for me: An extended struct with a core field.

I've done a bit of searching, and it seems like there's a general consensus that support levels are relative (not absolute) to it's parent object/field.

The documentation speaks to a particular situation where the parent has a dynamic support level depending on the object within which it is utilized: https://github.com/kubernetes-sigs/gateway-api/blob/efe23a0d6ad8816ec5246a8ea7004cc2c6c469f9/site-src/concepts/conformance.md?plain=1#L49-L55

However, I'm struggling with the sentence: Fields within this struct may express separate Core and Extended support levels, but those levels must not be interpreted as exceeding the support level of the parent struct they are embedded in.

Is this saying:

• At all times (even in relative terms), Core fields with Extended structs as parents should be interpreted not as Core but rather as Extended.
• Or is this trying to clarify that fields are indeed relative to their parent?

What you expected to happen:

Either clarity regarding nested support levels, or an explanation that I'm misinterpreting the docs that already provide enough clarity and closing of this issue.

How to reproduce it (as minimally and precisely as possible):

1. Be me
2. Read the overlapping-support-levels docs
3. Slightly confused

Anything else we need to know?:

Related issue: https://github.com/kubernetes-sigs/gateway-api/issues/655

Real Life Example of nested Core Support in Extended Struct:

• GRPCRoute struct is Extended, but has spec.hostnames as Core

Bonus questions:

• Is it valid to have a Core struct with all Extended fields?
• Can you have a required (via CRD validation) Extended field?

Thanks.

[youngnick]

Thinking back here, I think the way I expected this to work is that if something in Extended contains Core fields, it should be interpreted as "The overall behavior is Extended, but if you do that Extended behavior, you must do the Core things inside that thing."

An example here is Core fields inside Extended objects - if you support the Extended object, you must do the Core things inside that object. So for the GRPCRoute example above, you don't have to support the GRPCRoute object, but if you do, you have to support the spec.hostnames field.

Another way to think of this is that "Extended" == "Optional plus Conformance Tested", "Core" == "Not optional plus conformance tested", and "ImplementationSpecific" == "Optional, no tests".

Does that make sense?

[shaneutt]

I think it's probably reasonably intuitive to think if something under extended is labeld "core", it means you have to implement it IF you implement the extended feature.

At a language, and technical level however using "core" for this seems to dilute the meaning of "core".

At minimum it would at least be good to document this further so it's nice and clear if we decide this is how we intend to do this. At best it might be good to come up with different language to differentiate "required sub-feature of extended features".

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.