ContainerPort protocol is a key field, which makes it required for server-side apply #130
Description
Hi,
I was playing around with server-side apply and hit into a problem. Say I have a pod like this (very reduced case of course):
# pod.yml
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: test
ports:
- containerPort: 1234If I run kubectl apply -f pod.yml --server-side I get the following error:
Error from server: failed to create typed patch object: .spec.containers[name="test"].ports: element 0: associative list with keys has an element that omits key field "protocol"
This is unexpected, because ContainerPort specifies the protocol as an optional field, which defaults to TCP. I traced this error back to this repository, so I figured this is where it could be resolved.
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-16T01:01:59Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
bouk commentedon Nov 28, 2019
I think keeping this restriction in will hamper the adoption of server-side applies greatly, for example the ingress-nginx config also misses the 'protocol' ports in its config: https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/provider/cloud-generic.yaml
cc @lavalamp
deploy: add protocol to all Container/ServicePorts
apelisse commentedon Dec 2, 2019
Thanks @bouk, we're aware of this bug and we do want to fix it, thanks.
We have #83 that partially fixes it (still trying to figure out the best solution).
/assign @jennybuckley
fejta-bot commentedon Mar 1, 2020
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 commentedon Mar 31, 2020
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
fejta-bot commentedon May 1, 2020
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
k8s-ci-robot commentedon May 1, 2020
@fejta-bot: Closing 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.
apelisse commentedon May 1, 2020
/reopen
We care about this more than ever.
45 remaining items
protocol: TCPvalue underportskey to avoid the known limitation for Kubernetes 1.19 open-telemetry/opentelemetry-operator#370protocol: TCPvalue underportskey to avoid the known limitation for Kubernetes 1.19 open-o11y/opentelemetry-operator#21protocol: TCPvalue underportskey to avoid the known limitation for Kubernetes 1.19 open-telemetry/opentelemetry-operator#372