GEP 1709: initial implementation ideas

[shaneutt]

What type of PR is this?

/kind gep

What this PR does / why we need it:

This contributes to #1709 and #1329 by adding the initial ideas for an implementation of conformance profiles to the relevant GEP.

Please note that the GEP remains in provisional state for this iteration so nothing that merges here is necessarily set in stone. Therefore if you have some lingering questions or concerns there will be more time to voice those concerns, and ideally even make your own PR making the changes that you want to see and helping co-author the GEP to pull in your ideas!

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[shaneutt]

@sunjayBhatia I'm marking this one as a merge hold for the moment to make sure we hear back from you as a stakeholder before we merge it.

[LiorLieberman]

I like the changes. Thanks!

/lgtm
/approve

[sunjayBhatia]

looks great to me 👍🏽

I think regardless of how the implementation details etc. shake out (in terms of reporting schema, command line flags, etc.) I think the core ideas of what we want to get out of the centralized profiles/reporting are there!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arkodg, LiorLieberman, shaneutt, sunjayBhatia

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 [shaneutt]

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

[shaneutt]

@youngnick as I understand it you wanted to give this a pass too, so keeping the hold on it until you've had a chance. Please feel free to remove the hold once you're happy with it 👍

[youngnick]

This LGTM, I think a couple of things I consider imperative are already sorted here, nice work:

• Using SkipTests on any Core features means you're not conformant
• The output is machine parsable.

The one thing I'd add, non-blocking though, is an example of what the YAML would look like with failed tests. Not that I think anyone would submit that, but it will make it clearer for implementors.

Oh, and it would be good to add that the summary fields are free-form, we shouldn't require specific values there, or have that output be parsed or interpreted.

[shaneutt]

• Using SkipTests on any Core features means you're not conformant
• The output is machine parsable.
• The one thing I'd add, non-blocking though, is an example of what the YAML would look like with failed tests.

These things are already accounted for in the document:

https://github.com/kubernetes-sigs/gateway-api/pull/1754/files#diff-7764ccb47f68a80348b14a2c6df6c6cadd80db02de7817dbcb8039a611bf1328R127
https://github.com/kubernetes-sigs/gateway-api/pull/1754/files#diff-7764ccb47f68a80348b14a2c6df6c6cadd80db02de7817dbcb8039a611bf1328R369

Oh, and it would be good to add that the descriptions are free-form, we shouldn't require specific values there.

This one wasn't accounted for yet, I've added this in 6489c36 👍

[youngnick]

/lgtm
/unhold