core/v1: document that topologyKeys requires the ServiceTopology feature gate #96528
Conversation
…ure gate Signed-off-by: Andrew Sy Kim <[email protected]>
k8s-ci-robot
added
release-note
|
@andrewsykim: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
k8s-ci-robot
added
needs-priority
k8s-ci-robot
removed
the
do-not-merge/needs-sig
|
/assign @thockin |
| @@ -3710,6 +3710,7 @@ type ServiceSpec struct { | |||
| // The special value "*" may be used to mean "any topology". This catch-all | |||
| // value, if used, only makes sense as the last value in the list. | |||
| // If this is not specified or empty, no topology constraints will be applied. | |||
| // This field is alpha-level and is only honored by servers that enable the ServiceTopology feature. | |||
There was a problem hiding this comment.
should we just deprecate this now to start the clock?
There was a problem hiding this comment.
Why should this be deprecated ? Is ServiceTopology feature not being used anymore ?
There was a problem hiding this comment.
Yes. It was an alpha design that we decided there are better answers to. SO we are deprecating the API for it and will eventually remove it.
There was a problem hiding this comment.
Can you suggest some alternatives to achieve the same effect ? Basically to preferentially route traffic based on the cluster topology ?
There was a problem hiding this comment.
For posterity, this is being built into kube-proxy as Topology Aware proxying
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
|
Thanks! /lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewsykim, thockin 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
|
Well, you can keep using the alpha for now, but eventually it will just be
automatic.
…On Tue, Jan 26, 2021, 8:09 PM Fredrick Prashanth John Berchmans < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In pkg/apis/core/types.go
<#96528 (comment)>
:
> @@ -3710,6 +3710,7 @@ type ServiceSpec struct {
// The special value "*" may be used to mean "any topology". This catch-all
// value, if used, only makes sense as the last value in the list.
// If this is not specified or empty, no topology constraints will be applied.
+ // This field is alpha-level and is only honored by servers that enable the ServiceTopology feature.
Can you suggest some alternatives to achieve the same effect ? Basically
to preferentially route traffic based on the cluster topology ?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#96528 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKWAVEDSXXAAGU4KYSHTCLS36GXRANCNFSM4TTWLPRA>
.
|
Signed-off-by: Andrew Sy Kim [email protected]
What type of PR is this?
/kind documentation
/kind api-change
What this PR does / why we need it:
Document that the ServiceTopology feature gate is required to use the topolgoyKeys API.
Even though we are going to remove this feature in the future, we should document this requirement since there may be users wanting to try to use this feature gate with the gate disabled.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: