[GEP-2162] Updated a new field on report for supported features inference from boolean to enum.

[bexxmodd]

What type of PR is this? /kind feature /kind gep /area conformance-test

What this PR does / why we need it: This is an update from boolean flag to enum for the report that should capture case when Conformance profile is Mesh without GWC and we can't infer supported features.

Does this PR introduce a user-facing change?: None

[k8s-ci-robot]

Hi @bexxmodd. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[youngnick]

Change overall looks good with some minor changes to make things more readable.

/ok-to-test

[LiorLieberman]

/cc

[youngnick]

This LGTM but I'll defer to @mlavacca for a final approval.

[k8s-ci-robot]

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

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

In response to this:

However, there is a fourth case that I'd like to figure out, which is Gateway profiles and Mesh profiles together: I don't think mesh features should be set in the GWC status, so how do we proceed in this case?

Right now, implementations that are both a Gateway and a Mesh implementation, do have gateway class, and the current state is that they report (or will report) their supportedFeatures (mesh features included) on GWC. From here we can go to either direction:

1. Change the guidance to not report Mesh related features on GatewayClass. When a Mesh resource is introduced (if it is introduced cc: @kflynn) or when we figure out a different way for inferring mesh features, we are updating the GEP to guide implementations to report there.

2. We let this dual implementations (mesh and gateway) publish Mesh features on GWC. And later if there is additional Mesh resource introduced, they can migrate there.

I think 1) is cleaner. However it would require those implementations to provide Mesh Features manually, and more complex code in the suite.

I think 2) is more straightforward.

If we go with 1) the way to handle this is provide inferred stamp in case no non-mesh features were provided. (potentially we introduce a new flag for "mesh-features" to enforce it more cleanly, or we just check based on Mesh prefix)

/cc @mikemorris @kflynn @howardjohn for addtl feedback

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-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bexxmodd, mlavacca

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:

• ~~conformance/OWNERS~~ [mlavacca]

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

[LiorLieberman]

/cc @mikemorris @kflynn @mlavacca for final review and feedback on https://github.com/kubernetes-sigs/gateway-api/pull/3885#discussion_r2190677320

[robscott]

Thanks @bexxmodd!

/lgtm /hold cancel