Re: [kubernetes/kubernetes] apiserver allows duplicate service port (#59119)
k8s-ci-robot
@DirectXMan12: GitHub didn't allow me to assign the following users: RobertKrawitz.
Note that only kubernetes members and repo collaborators can be assigned.
In response to this:
/assign @RobertKrawitz
@kubernetes/sig-api-machinery-bugs how do we want approach fixing this?
@liggitt I seem to recall you having opinions on patch in the past...
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.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Solly Ross
/assign @RobertKrawitz
@kubernetes/sig-api-machinery-bugs how do we want approach fixing this?
@liggitt I seem to recall you having opinions on patch in the past...
—
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
James Ravn
/remove-lifecycle stale
Daniel Smith
fully reified (i.e., post-patch-application) objects.
On Tue, May 15, 2018 at 7:21 AM James Ravn <notifi...@github.com> wrote:
> /remove-lifecycle stale
>
> —
> You are receiving this because you are on a team that was mentioned.
> Reply to this email directly, view it on GitHub
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAngljN0LEg-EDC63Wbo7ScTI8PPLZcKks5tyuR-gaJpZM4R0TE1>
> .
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
—
You are receiving this because you are on a team that was mentioned.
jethrogb
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
jethrogb
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
James Ravn
/remove-lifecycle stale
Tim Hockin
I confirm this still exists and the analysis by @RobertKrawitz is excellent and very plausible.
WORSE -- it will consider two ports as identical even if they differ in protocol. Looking at types.go:
// The list of ports that are exposed by this service.
// More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
// +patchMergeKey=port
// +patchStrategy=merge
// +listType=map
// +listMapKey=port
// +listMapKey=protocol
Ports []ServicePort `json:"ports,omitempty" patchStrategy:"merge" patchMergeKey:"port" protobuf:"bytes,1,rep,name=ports"`
So dear api-machinery people -- how should we be approaching this? The correct key is really the protocol + port (at minimum) but more even then the original problem exists. This should really be an error...
SaintLiber
Server: v1.14.0
Client: v1.14.0
Patch URI: https://172.18.141.129:6443/api/v1/namespaces/default/services/example
BODY:
{
"spec":{
"ports":[
{
"name":"port-0",
"port":6666,
"protocol":"TCP",
"targetPort":6666
}
]
}
}
Response:
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Service "example" is invalid: spec.ports[1].name: Duplicate value: "port-0"","reason":"Invalid","details":{"name":"example","kind":"Service","causes":[{"reason":"FieldValueDuplicate","message":"Duplicate value: "port-0"","field":"spec.ports[1].name"}]},"code":422}
The Service "example" is invalid: spec.ports[1].name: Duplicate value: "port-0"
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
—
Mike Miller
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
jethrogb
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
jethrogb
/remove-lifecycle rotten
Daniel Smith
I believe SSA code should reject this. I am not sure if we're failing requests yet when SSA barfs (@apelisse probably knows). We are slightly worried about making client requests that used to "work" stop working. In this case the result is clearly garbage so that's probably not an issue.
(sorry for extremely delayed response, this is the first I saw the issue in my email)
Tim Hockin
@apelisse This is popping up again - any thoughts on how to crack this?
Antoine Pelisse
I believe SSA code should reject this. I am not sure if we're failing requests yet when SSA barfs (@apelisse probably knows).
We do.
My understanding is that there is a difference between the manually written validation and the openapi extensions (patchMergeKey) semantics, so the patch (build by kubectl using openapi) and the create/update don't behave the same way.
Server-side apply will help address the apply case in the future, and probably solve the problem altogether if you server-side apply to create and update. Eventually we should fix the validation (probably when we have ratcheting) so that either we use the openapi for validation on all types of requests, or either by validating that there are no duplicate keys.
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
jethrogb
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
jethrogb
/remove-lifecycle rotten
Jordan Liggitt
duplicate report in #97883
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
James Ravn
/remove-lifecycle stale
nurhun
I'm facing same issue, k3s cluster v1.21.2+k3s1
Daniel Smith
Is this still a problem if SSA is used (kubectl apply --server-side)? If so, what is the failure point now?
Kubernetes Triage Robot
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
jethrogb
/remove-lifecycle stale
Tim Hockin
See #103544 for status.
Tim Hockin
Closed #59119.