Conformance display profiles on gatewayapi docs

[xtineskim]

trafficstars

What type of PR is this? /kind documentation

What this PR does / why we need it: Related to https://github.com/kubernetes-sigs/gateway-api/issues/2550. tldr, we lack a way to quickly show different implementations of the Gateway API and their features. After trying various plugins for mkdocs, the most convenient was a markdown table that could be sorted based on columns. Not the most ideal experience, but it's a start for showing conformance profile reports on the gateway api site Which issue(s) this PR fixes: https://github.com/kubernetes-sigs/gateway-api/issues/2550 (although this will need more iteration in the future.It's a start)

Fixes #

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

Hi @xtineskim. 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/test-infra repository.

[shaneutt]

/cc @robscott @youngnick @mlavacca @sunjayBhatia

[robscott]

Thanks @xtineskim!

/ok-to-test

[sunjayBhatia]

deploy preview table: https://deploy-preview-2874--kubernetes-sigs-gateway-api.netlify.app/implementation-table/

[robscott]

Thanks for all the work on this @xtineskim! This is great to see! Would it make sense to have a structure that looked something like this?

Gateway Profile

HTTPRoute

	BackendTimeout	HostRewrite	MethodMatching	ParentRefPort	PathRedirect	PathRewrite	PortRedirect	...
Cilium	✅	✅	✅	✅	✅	✅	✅	...
Kong	✅	❌	✅	❌	❌	❌	❌	...
...

Mesh Profile

HTTPRoute

	BackendTimeout	HostRewrite	MethodMatching	ParentRefPort	PathRedirect	PathRewrite	PortRedirect	...
Kuma	✅	✅	✅	✅	✅	✅	✅	...
Istio	✅	❌	✅	❌	❌	❌	❌	...
...

^ Those are not accurate, but hopefully they illustrate the general idea.

All of the above would unfortunately rely on a lot of horizontal scrolling for now, but maybe eventually we could further segment that out further to have different categories of features grouped together in different tables (even within HTTPRoute).

As a bit of inspiration, there's also this incredibly helpful spreadsheet for ingress controllers that had a lot of the same goals we're trying to accomplish here.

[sunjayBhatia]

As a bit of inspiration, there's also this incredibly helpful spreadsheet for ingress controllers that had a lot of the same goals we're trying to accomplish here.

+1 to this approach, agreed its super helpful to see laid out like this

[xtineskim]

@mlavacca thanks for your input! I think with @candita's comment about having abbreviated names (maybe not in this pr), I think it would be better. I'll make the changes to switch the axis

Per your comments listed:

1. for each Gateway API Version, an implementation can submit multiple reports for different implementation versions

Currently I am just grabbing the latest report uploaded (nginx, contour both have 2 yaml reports, but i sort the versions and keep the latest one). I'm hoping that as new conformance reports are generated, all the profiles will be included in the latest report

2.for each Gateway API version and implementation version, there can be multiple reports related to the modes

Ah good catch with the mode, I forgot that use case (reference for others). I haven't seen any project report use that field either (yet). To address this, I can add a filter for mode for the loaded dataframes to look for the mode type, but also add in the default mode for current projects. Thanks for the reminder on this!

3.an organization can have multiple projects

I'm assuming though that this will have it's own folder, and a different project name? And if the project name is different, that shouldn't be a problem 👍

[xtineskim]

@robscott thank you for the suggestions! 🤝 slowly addressing the above comments, and i like the proposal of having the Gateway Profile and the Mesh Profile. Just a few q's:

• The Mesh Profiles information are pulled from the name of MESH in the reports (for example kuma's. Not sure if naming of MESH will have to be changed in the future if other routes will be added under the MESH conformance? I guess just assume keeping it for HTTPRoute for now?
• Should I still have the Kuma listed under the Gateway Profile as well for HTTPRoute (pulling from this part of the report).

[robscott]

The Mesh Profiles information are pulled from the name of MESH in the reports (for example kuma's. Not sure if naming of MESH will have to be changed in the future if other routes will be added under the MESH conformance? I guess just assume keeping it for HTTPRoute for now?

This is actually one of my concerns with the current names of the conformance profiles. I think we may want to just settle on "mesh" and "gateway" conformance profiles and then have per-route details covered by the supported features. Interested in what @shaneutt and @mlavacca think about that though.

Should I still have the Kuma listed under the Gateway Profile as well for HTTPRoute (pulling from this part of the report).

Yes, I think both Kuma and Istio support the Mesh and Gateway concepts in Gateway API, so they'd be covered under both sections.

[michaelbeaumont]

Should I still have the Kuma listed under the Gateway Profile as well for HTTPRoute (pulling from this part of the report).

Yes, I think both Kuma and Istio support the Mesh and Gateway concepts in Gateway API, so they'd be covered under both sections.

Yep, Kuma does indeed support HTTPRoute for both Mesh and Gateway!

[mikemorris]

Confirming that Istio likewise supports HTTPRoute for both gateway and mesh use cases. This visualization is looking great and should be quite helpful in guiding users looking to adopt Gateway API!

[robscott]

Thanks @xtineskim, this is a great addition!

/lgtm /approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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