search

kubernetes-sigs / gateway-api

Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
https://gateway-api.sigs.k8s.io
Apache License 2.0
1.83k stars 479 forks source link

Goals (or boundary) of the Gateway API project #1815

Closed arkodg closed 8 months ago

arkodg commented 1 year ago

What would you like to be added: A high level document highlighting goals of the project

Why this is needed: With the announcement that Gateway API is planning on graduating to GA soon, (which is great news !), a high level document highlighting goals of the project would help

For e.g. lets take the OIDC based Authentication feature, this is a common ask from users (slack ref), hoping the goals doc helps reveal whether

youngnick commented 1 year ago

Sorry for the delay on this one @arkodg.

I think it's difficult to make a call about which features will be supported natively, because we've designed the conformance levels to imply a possible flow for features (namely, ImplementationSpecific -> Extended -> Core ).

The idea is that, to help us all move faster, people can experiment with ImplementationSpecific things, then if we find something ImplementationSpecific is in wide use, we can bring it into Extended (which will include making it part of native support).

I don't think that any feature work done using one of the standard extension points will be wasted, and I'd be pretty reluctant to say "never" for any feature.

That said, I think that for OIDC auth, it seems likely that it will both widely desired and widely supportable, so it seems reasonable that it would end up in Extended eventually (assuming we can agree on the design).

The reason for this is that, over the years we've been doing this, we've found that it's very easy to spend a lot of time arguing about design in the absence of data from trying to implement some feature, and that encouraging people to prototype something first helps cut the solution space down much more quickly.

At the end of the day, the overall goal of the project is to support as many features as we can make Portable, Extensible, and Role-Oriented. So unless something is very ImplementationSpecific, I think it's unlikely it will Never be supported, it will just need development time.

We have been (and still are) focussing on trying to get the core parts of the API right first (including both API contructs like Gateway and GatewwayClass etc), and getting processes like conformance set up and running. I think that once we start graduating resources to GA and finish with this more basic work, we will be able to increase the velocity of delivering extra, highly-useful features like authentication, rate-limiting, and so on.

arkodg commented 1 year ago

thanks for commenting @youngnick, this is very helpful and should help end users as well as implementors better understand what Gateway API can eventually support.

would be great to convert above comment in a goals/scope section for the website. I'm happy to help out with that ( I'll try to paraphrase above comment )

youngnick commented 1 year ago

Yes, I agree that would be great @arkodg! If you want to do that, sounds awesome. I think our initial landing pages need an update anyway.

arkodg commented 1 year ago

/assign

k8s-triage-robot commented 1 year ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 9 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot commented 8 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 8 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-sigs/gateway-api/issues/1815#issuecomment-1951060597): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.