Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore: cleanup TODO list and alternatives considered for GEP 1709 #2051

Merged
merged 4 commits into from
May 22, 2023
Merged

chore: cleanup TODO list and alternatives considered for GEP 1709 #2051

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b26b849
docs: remove mesh alternative from GEP 1709
shaneutt May 22, 2023
10c2162
docs: consider SIG Arch feedback required
shaneutt May 22, 2023
8421986
docs: remove RG separation from GEP 1709
shaneutt May 22, 2023
1796b3f
docs: GEP 1709 require display post experimental
shaneutt May 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 15 additions & 31 deletions geps/gep-1709.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,32 +12,24 @@ the Gateway API project and receive recognition (e.g. badges).

## TODO

The following are items that we intend to resolve before we consider this GEP
`implementable`:

- We still need to sort out how we're going to display conformance results.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check the commit history, it got moved down to "required to move past experimental" rather than "required to consider implementable. The thinking here is that the machinery we have provides a surface well enough for practically any display layer to be built on top, so it doesn't need to block (in fact, doesn't need to block GA) that we have a fancy display layer.

Badges are well and good, but we also want some kind of summarized
display of any given implementation's conformance results somewhere on
our upstream website (so far the thought has been the [implementations
page][impl]). We should look for prior art in Kubernetes SIGs and also
reach out to some frontend developers to come up with something really
solid prior to moving to `implementable`.
The following are items that **MUST** be resolved before we move past the
`provisioning/prototyping` status:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiny nit: "Provisional"


- We need to think about how we're going to highlight and report on the
results for `experimental` features, and make sure this is explicitly
written out.
- We are [gathering feedback from SIG Arch][sig-arch-feedback]. We need to let
this soak for some time, bring up the topic at SIG Arch community meetings, and
generally make changes according to their feedback before considering this
`implementable`.
- Right now we've said that `GatewayClass` and `Gateway` tests will be
implicitly added to testing profiles were they are referenced, but we're
not sure yet whether this is going to work out for `ReferenceGrant` as we
know of at least one implementation that explicitly doesn't support it.
Comment on lines -32 to -35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this one removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check the commit history, the commit includes an extended comment which explains: basically we decided to go the other way and implicitly added ReferenceGrant tests to profiles. It seems this might actually be fine for all implementations, if not we technically allow the feature to be disabled.

It's possible `ReferenceGrant` is just a special case for a profile we'll
have to allow opting into or out of, or maybe some other optional way to do
this but still be conformant. Needs to be resolved before we move to
`implementable` as `ReferenceGrant` is already in BETA and is being
considered in other areas of Kubernetes.

The following are items that **MUST** be resolved before we move past the
`experimental` status:

- We have been actively [gathering feedback from SIG Arch][sig-arch-feedback].
Some time during the `experimental` phase needs to be allowed to continue to
engage with SIG Arch and incorporate their feedback into the test suite.
- We need to sort out how we're going to display conformance results. We want
some kind of summarized display of any given implementation's conformance
results somewhere on our upstream website (so far the thought has been the
[implementations page][impl]). We should look for prior art in Kubernetes
SIGs and also reach out to some frontend developers.

[sig-arch-feedback]:https://groups.google.com/g/kubernetes-sig-architecture/c/YjrVZ4NJQiA/m/7Qg7ScddBwAJ

Expand Down Expand Up @@ -582,14 +574,6 @@ iteration to add this if desired, but it probably warrants its own GEP as we
need to make sure we have buy-in from multiple stakeholders with different
implementations that are implementing those features.

### Mesh Profiles

We eventually want profiles for GAMMA/mesh related tests, however at this point
we believe the test suite for mesh could end up being it's own separate thing
so it's not a part of this GEP for now, but we should make sure our tooling is
modular and composable so if we do end up with an eventual mesh conformance
test suite, it can employ conformance profiles and reporting as-is.

### High Level Profiles

We originally started with two high level profiles:
Expand Down