Update GEP-1762 with Gateway name limit recommendations #3070
Conversation
Also updates Gateway resource to recommend users create Gateways with <= 63 character names. Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
k8s-ci-robot
added
release-note
k8s-ci-robot
added
the
size/XS
| @@ -32,6 +32,10 @@ import ( | |||
|
|
|||
| // Gateway represents an instance of a service-traffic handling infrastructure | |||
| // by binding Listeners to a set of IP addresses. | |||
| // | |||
| // It is recommended that the Gateway name field be limited to a maximum length | |||
| // of 63 characters. Gateway names may be used in label values on generated | |||
There was a problem hiding this comment.
It seems like 63 is too long if 63 is the max length of some of the values we're trying to populate. Ideally wouldn't you want to translate foo-gateway to a generated contour-foo-gateway or similar? I'm also not sure if this belongs in the API spec or should just be in more user-facing guidelines documentation for using the API.
There was a problem hiding this comment.
63 is the max label value length, this shouldn't have any immediate bearing on generated resource names
There was a problem hiding this comment.
I can move this to another guide instead though if that is preferred, maybe better here: https://gateway-api.sigs.k8s.io/api-types/gateway/
There was a problem hiding this comment.
63 is the max label value length, this shouldn't have any immediate bearing on generated resource names
🤦 did not read this closely enough, nevermind.
I can move this to another guide instead
We don't really have any strong guidance here as far as where user-facing tips like this belongs. Generally we reserve RFC language like SHOULD and MUST in the API Spec for implementation guidance, but it also feels weird to have "It is recommended" instead of "SHOULD" here. I can't really think of better solutions here, but interested in what @youngnick thinks.
There was a problem hiding this comment.
Thanks @sunjayBhatia! Let's give a few days for @youngnick to look at this in case he has better ideas for where this guidance could go. If not, I'm fine with some lazy consensus where we can just remove the hold sometime next week if no strong opinions emerge.
/lgtm
/approve
/hold for second opinion
| @@ -32,6 +32,10 @@ import ( | |||
|
|
|||
| // Gateway represents an instance of a service-traffic handling infrastructure | |||
| // by binding Listeners to a set of IP addresses. | |||
| // | |||
| // It is recommended that the Gateway name field be limited to a maximum length | |||
| // of 63 characters. Gateway names may be used in label values on generated | |||
There was a problem hiding this comment.
63 is the max label value length, this shouldn't have any immediate bearing on generated resource names
🤦 did not read this closely enough, nevermind.
I can move this to another guide instead
We don't really have any strong guidance here as far as where user-facing tips like this belongs. Generally we reserve RFC language like SHOULD and MUST in the API Spec for implementation guidance, but it also feels weird to have "It is recommended" instead of "SHOULD" here. I can't really think of better solutions here, but interested in what @youngnick thinks.
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arkodg, robscott, 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
What type of PR is this?
/kind cleanup
/kind documentation
/kind gep
What this PR does / why we need it:
Updates GEP-1762 to provide guidance for implementers on what to do with the
gateway.networking.k8s.io/gateway-name(to be put on generated in-cluster resources) when a Gateway's name exceeds 63 characters (the label value length limit).Also updates Gateway resource to recommend users create Gateways with <= 63 character names.
Which issue(s) this PR fixes:
Fixes #2592
Does this PR introduce a user-facing change?: