-
Notifications
You must be signed in to change notification settings - Fork 480
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.
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
GEP-1762 needs clarification on long Gateway names > 63 characters #2592
Comments
vote for 2. (limit gateway names to < 63) |
I agree this is suboptimal as we will lose the immediate human readability of this feature.
Limiting the name's length is quite tricky as what behavior should we expect?
We could use a label selector on gateways with length < 63. Here the problem is that we should enforce uniqueness on this field among all the gateways in every namespace and I'm not sure there is some kind of validation at kubebuilder or CEL level that can enforce this. |
Unfortunately I think it's too late to add any kind of limit here - Gateway is a GA part of the API. Even if we could, almost all Kubernetes resources follow the same default name validation, and I don't think it it would make sense to change it here. I think many/most Kubernetes tools will use some kind of combination of truncation and hashing when dealing with long names in places they don't fit. So although it adds additional work, it's probably good that we have conformance tests that cover longer Gateway names like this. |
Yep, that makes a lot of sense. I guess at the moment, unless anyone disagrees, the action item here is to update the GEP (and any other places we talk about labels perhaps) to have a prescriptive way to deal with long resource (specifically Gateway) names being added as labels |
@robscott can we consider adding text in the API to discourage longer than 63 chars in the name ? |
Even without any hard restrictions on the API, we should add documentation to mention this possibility. |
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 |
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 |
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-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
/reopen @howardjohn can you work on this? |
@robscott: Reopened this issue. In response to this:
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. |
If noone has picked this up I can take it since it looks like we got some consensus above on documentation/recommendation updates |
Thanks @sunjayBhatia! /assign @sunjayBhatia |
PR: #3070 |
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-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
What happened:
Prior to GEP-1762, Contour's Gateway provisioner has been adding a label to resources to denote which Gateway "owns" it:
projectcontour.io/owning-gateway-name
set to the Gateway name.While reviewing #2582 with Contour and also implementing the Gateway infrastructure labels feature, we realized that Gateway names longer than 63 characters cause failures to create resources generated with this label.
While this can be solved for Contour's implementation-specific labels with a hash or some other solution, this is not exclusive to Contour, the upstream GEP-1762 also has requirements that may cause many implementations to run into this. Also, including a conformance test that exhibits this may be problematic for some implementations.
@skriss pointed out as well that GEP-1762 makes this same type of label, including the "owning" Gateway as the value, required for implementations that generate deployment resources dynamically: https://gateway-api.sigs.k8s.io/geps/gep-1762/#automated-deployments
What you expected to happen:
GEP-1762 should be amended to describe what to do with the
gateway.networking.k8s.io/gateway-name
label when dealing with a Gateway with a long name.How to reproduce it (as minimally and precisely as possible):
Run the conformance test
HTTPRouteInvalidParentRefSectionNameNotMatchingPort
(onmain
) with Contour, or create a Gateway with a name longer than 63 characters and have Contour reconcile it.Anything else we need to know?:
Hashing a long Gateway name and setting that as the value of may be an answer, however that means we will lose the immediate human readability of this feature.
Another solution would be to limit Gateway names to < 63 characters and longer names would not be Accepted by implementations.
The text was updated successfully, but these errors were encountered: