apis: add GatewayClassConditionReason Unsupported

[mikemorris]

...and clarifies the description for when GatewayClassConditionReason InvalidParameters should be preferred.

I considered adding something like GatewayClassConditionType ResolvedRefs with GatewayClassConditionType InvalidParametersRef as a more spec-consistent way to handle an invalid parametersRef reference as distinct from malformed content, but that felt like too big a change given that the documentation for the parametersRef field currently states:

If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true.

EDIT: Although now that I read that, that sentence needs to be reworded to be accurate.

What type of PR is this?
/kind documentation
/area conformance

What this PR does / why we need it:
Adds an appropriate reason for implementations (such as those of cloud vendors) which provide their own fixed GatewayClass offerings and do not support manually created GatewayClass resources.

Which issue(s) this PR fixes:
Provides an appropriate status condition reason to set for the GatewayClassObservedGeneration test currently skipped and blocking Azure Application Gateway for Containers full conformance in #3021

Does this PR introduce a user-facing change?:

Adds the GatewayClassConditionReason "Unsupported" and clarifies when GatewayClassConditionReason "InvalidParameters" should be preferred.

/cc @robscott @youngnick @snehachhabria

[k8s-ci-robot]

@mikemorris: The label(s) kind/conformance cannot be applied, because the repository doesn't have them.

In response to this:

...and clarifies the description for when GatewayClassConditionReason InvalidParameters should be preferred.

I considered adding something like GatewayClassConditionType ResolvedRefs with GatewayClassConditionType InvalidParametersRef as a more spec-consistent way to handle an invalid parametersRef reference as distinct from malformed content, but that felt like too big a change given that the documentation for the parametersRef field currently states:

If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true.

What type of PR is this?
/kind documentation
/kind conformance

What this PR does / why we need it:
Adds an appropriate reason for implementations (such as those of cloud vendors) which provide their own fixed GatewayClass offerings and do not support manually created GatewayClass resources.

Which issue(s) this PR fixes:
Provides an appropriate status condition reason to set for the GatewayClassObservedGeneration test currently skipped and blocking Azure Application Gateway for Containers full conformance in #3021

Does this PR introduce a user-facing change?:

Adds the GatewayClassConditionReason "Invalid" and clarifies when GatewayClassConditionReason "InvalidParameters" should be preferred.

/cc @robscott @youngnick @snehachhabria

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.

[k8s-ci-robot]

@mikemorris: GitHub didn't allow me to request PR reviews from the following users: snehachhabria.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

...and clarifies the description for when GatewayClassConditionReason InvalidParameters should be preferred.

I considered adding something like GatewayClassConditionType ResolvedRefs with GatewayClassConditionType InvalidParametersRef as a more spec-consistent way to handle an invalid parametersRef reference as distinct from malformed content, but that felt like too big a change given that the documentation for the parametersRef field currently states:

If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true.

What type of PR is this?
/kind documentation
/kind conformance

What this PR does / why we need it:
Adds an appropriate reason for implementations (such as those of cloud vendors) which provide their own fixed GatewayClass offerings and do not support manually created GatewayClass resources.

Which issue(s) this PR fixes:
Provides an appropriate status condition reason to set for the GatewayClassObservedGeneration test currently skipped and blocking Azure Application Gateway for Containers full conformance in #3021

Does this PR introduce a user-facing change?:

Adds the GatewayClassConditionReason "Invalid" and clarifies when GatewayClassConditionReason "InvalidParameters" should be preferred.

/cc @robscott @youngnick @snehachhabria

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.

[robscott]

Thanks @mikemorris!

[robscott]

Since there's not really much to a GatewayClass, it may be slightly more accurate to use "Unsupported" here if custom GatewayClasses just aren't supported. I think either are probably fine here, interested in what others think.

[mikemorris]

I'd be happy with Unsupported instead if folks would prefer that!

[snehachhabria]

I feel Unsupported is a better than Invalid as its a more accurate reason even if a message is or is not provided. Invalid can have a wider scope.

[mikemorris]

/retest

Is this Docker builder removal timeout issue with CI documented anywhere as needing a fix yet?

[robscott]

@mikemorris would it be ok if we held off on merging this until post-v1.1? I'm completely on board with the change, but hate to make any changes to CRDs/API Spec between RC2 and final release. Maybe implementations could just manually add this condition until it was formally added here?

[robscott]

Is this Docker builder removal timeout issue with CI documented anywhere as needing a fix yet?

Nope, I think I asked about in Slack once, but really unsure who could help us figure this one out. As a short term fix, it might be worth splitting out our docker build verification into a separate task that doesn't run with the rest of our verification. We'd just need to rework our Makefile a bit and add a new task here: https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-sigs/gateway-api/gateway-api-config.yaml.

[mikemorris]

@mikemorris would it be ok if we held off on merging this until post-v1.1?

Sure, no objections to that!

[robscott]

Thanks @mikemorris!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikemorris, robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment