jiebi/CodeConvo huggingface dataset:
Code change:
func (o *ResourcesOptions) Validate() error { var err error if len(o.Limits) == 0 && len(o.Requests) == 0 { <del> return fmt.Errorf("you must specify an update to requests or limits (in the form of --requests/--limits)") </del> <ins> return fmt.Errorf("you must specify an update to requests or limits or  (in the form of --requests/--limits)") </ins> } o.ResourceRequirements, err = kubectl.HandleResourceRequirements(map[string]string{"limits": o.Limits, "requests": o.Requests})

Related discussion:
text: from https://k8s-
Really suspect this is
This is putting us into test-go post-commit run is broken
cc:
marked this p0 - if a fix isn't easy let's try to identify what introduced this and revert.
This flake on: 2016-10-30 07:19 PDT First instance: : It is flaking frequently, blocking PRs from getting merged, and slowing the submit queue ( at 75%). As on-call, I'm going to try and identify the cluprit and revert. Can use all help in doing so.
can you investigate whether your additional tests could cause this (by breaking the deployment of those pods, for instance) , Saad Ali wrote:
PR looks most suspect to me. It mucked with , and the errors we are seeing in each of the failures is related to : That PR was merged at Oct 30, 2016, 6:18 AM PDT and the first flake in was at Oct 30, 2016, 7:19 AM PDT. Thoughts? CC
I'm going to initiate a revert of to see if that fixes the issue
IMO we can just change the flaky test to not get pods but some other resources, such as deployments. We can't really expect to clean up pods immediately.
I'm going to proceed with revert (). Please feel free to send a follow up PR to handle this more gracefully.
Going to leave this opened until we have a few hours of runs with the revert. Want to verify, with some degree of certainty, that the revert took care of this flake.
We had 15 green runs of in a row. Considering this flake fixed.
Code change:
}) } } <ins> func TestGetExcludedChecks(t *testing.T) { type args struct { r *http.Request } tests := []struct { name string r    *http.Request want sets.String }{ {"Should have no excluded health checks", createGetRequestWithUrl("/healthz?verbose=true"), sets.NewString(), }, {"Should extract out the ping health check", createGetRequestWithUrl("/healthz?exclude=ping"), sets.NewString("ping"), }, {"Should extract out ping and log health check", createGetRequestWithUrl("/healthz?exclude=ping&exclude=log"), sets.NewString("ping", "log"), }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { if got := getExcludedChecks(tt.r); !reflect.DeepEqual(got, tt.want) { t.Errorf("getExcludedChecks() = %v, want %v", got, tt.want) } }) } } func createGetRequestWithUrl(rawUrlString string) *http.Request { url, _ := url.Parse(rawUrlString) return &http.Request{ Method: http.MethodGet, Proto:  "HTTP/1.1", URL:    url, } } </ins>

Related discussion:
text: What would you like to be : Add support to the kube-apiserver so that we can disable health-checks via query params. Why is this needed: Currently, the healthz endpoint is inflexible in that any and all health checks are currently executed when the endpoint is hit. Since the kube-apiserver only currently supports a liveness check, this means all persistent health check failures will eventually result in a kubelet driven restart. However, this may not be desirable behavior if you have additional monitoring services layered on top of your control plane. For instance, take the etcd failure from the perspective of the kube-apiserver. Currently, persistent failures during the etcd health check from the api-server healthz endpoint will cause the kube-apiserver to be restarted. This sometimes helps (in the case of a faulty etcd-client connection) but also can be detrimental (the kube-apiserver restarts until the etcd cluster is functioning, then the kube-apiserver bombards the etcd cluster with requests to update local caches, saturating the etcd cluster with requests, causing it to timeout on its own liveness probes and trigger a kubelet-driven restart). Let's say that we could now disable etcd from our liveness health check. Then if we had an external monitoring service, we could ask independently ask etcd if it was healthy and we could also ask the kube-apiserver if it thought etcd was unhealthy. Based on the combination of those answers, we could enable more intelligent responses to certain situation, like restarting the kube-apiserver when it thought etcd was unhealthy but etcd was actually reporting as healthy but not doing so when etcd was actually unhealthy. This feature is backwards-compatible and opt-in. There would be no impact to existing behavior unless these query params are actually used. /sig api-machinery /kind feature
/cc
SGTM
/assign
Code change:
* [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager <del> ###### Auto generated by spf13/cobra on 5-Apr-2016 </del> <ins> ###### Auto generated by spf13/cobra on 3-Jun-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_exec.md?pixel)]()

Related discussion:
text: Need to finish so the client allows you to select an init container, and verify the kubelet works correctly.
(this is a nice intersection of new in 1.3, node and usability, if anyone wants to give it a shot. Pretty sure Clayton is busier than I am and I don't think I'll get to it)
Will be happy to review any changes - should be fairly straightforward.
Yes, init containers are "run to completion" always. , harryz wrote:
IIUC when the init containers of pod have not complete, the pod should be in status, which means will fail, if init containers run to completion, they will exit, still fail. I don't know what you mean exec should work on init containers?
the init container is still up and running even when the pod is in pending, we should be able to exec and debug why it's hung, for example.
add a straightforward exec implementation ptal.
Code change:
result.User = os.Getenv("USER") } <del> if bastion := os.Getenv("KUBE_SSH_BASTION"); len(bastion) > 0 { </del> <ins> if bastion := os.Getenv(sshBastionEnvKey); len(bastion) > 0 { </ins> stdout, stderr, code, err := runSSHCommandViaBastion(cmd, result.User, bastion, host, signer) result.Stdout = stdout result.Stderr = stderr

Related discussion:
text: ci-kubernetes-e2e-gce-scale-correctness Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands kubetest.Test Jul 10 14:01:51 UTC+0200 Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands: more . Test /sig node
/cc
/triage accepted
Uhhh, this may help here
/milestone v1.22
/sig scalability FYI
I got annoyed that I couldn't click through to see the other logs, so now you can, ref: (spyglass doesn't render build- because it's 500MB, and the limit for rendering is 100MB)
/assign SIG Scalability chairs/TLs, please find someone to address or call this a non-release-blocking failure
Assigning to current scalability oncall (): /assign
This is sig-node issue - should be addres by SIG-node folks. /sig node
is being discussed as a fix for this and I'm not sure it's correct
is it sig scalability's intent that 5k node clusters should support SSH?
The SSH test in question passes in the "default" job: So the fact that this failure is unique to a scalability job means to me that scalability needs to own at least some part of this
I did a little bit of digging and ci-kubernetes-e2e-gce-scale-correctness uses option in kubetest, which according to seems to be setting KUBESSHBASTION env. So I believe this is main difference between our scalability job and "default".
Debugging the test in and providing a fix there. The crictl host PR () is doing something different.
Code change:
}) matchExpectations := ptrMatchAllFields(gstruct.Fields{ "Node": gstruct.MatchAllFields(gstruct.Fields{ <del> "NodeName":  Equal(framework.TestContext.NodeName), "StartTime": recent(maxStartAge), "SystemContainers": gstruct.MatchElements(summaryObjectID, gstruct.IgnoreExtras, gstruct.Elements{ "kubelet": sysContExpectations, "runtime": sysContExpectations, }), </del> <ins> "NodeName":         Equal(framework.TestContext.NodeName), "StartTime":        recent(maxStartAge), "SystemContainers": gstruct.MatchAllElements(summaryObjectID, systemContainers), </ins> "CPU": ptrMatchAllFields(gstruct.Fields{ "Time":                 recent(maxStatsAge), "UsageNanoCores":       bounded(100E3, 2E9),

Related discussion:
text: Kubernetes version (use ): 6 Environment: GCE What happened: I created a cluster for Heapster testing purposes to debug failing test in It turned out that Summary API does not export system/misc stats in SystemContainers section (though there are kubelet and docker stats). Everything works as expected on nodes. See also https://k8s-
What node OS were you using? We don't create the system (misc) container on systemd, so it's expected that GCI nodes don't report those stats.
The default configuration for 1.4, which is: master: GCI nodes: Container VM
Are the nodes running 1.4.6 too? There was a bug with this in 1.4.5, but it should have been fixed in 1.4.6.
Yes, both are running in 1.4.6. If you want to reproduce from Heapster current head run . It will take some time and as a side effect you should have a cluster with the mentioned problem. This was catch by integration tests and I temporary disabled the check here
if you have spare cycles, can you look into this?
friendly ping
Looking at it now
I have found a couple things so far. On the containerVM nodes, cadvisor is exporting a container with "name": "/system" On the GCI Master, cadvisor is exporting a container with "name": "" The has this: "{% set system_container = "--system-cgroups=/system" -%}" (/system is the default misc container name) So the real question is: Should cadvisor export "/system" instead of "" on GCI? Or should we be configuring GCI to use "--system-"?
I thought we fix this very issue for 1.4 branch by a while back. Are you running into the same issue with 1.5?
I think I told you the wrong thing earlier. We don't support the misc (/system) cgroup on systemd systems (I can't remember why, but it was an explicit decision - or might know). The is something different, I believe a base systemd cgroup (slice). As for the misc container on ContainerVM nodes, we've been testing for the misc container in 1.5+ in the summary api test (https://k8s-) for a while, and I haven't seen this issue.
Code change:
}) matchExpectations := ptrMatchAllFields(gstruct.Fields{ "Node": gstruct.MatchAllFields(gstruct.Fields{ <del> "NodeName":  Equal(framework.TestContext.NodeName), "StartTime": recent(maxStartAge), "SystemContainers": gstruct.MatchElements(summaryObjectID, gstruct.IgnoreExtras, gstruct.Elements{ "kubelet": sysContExpectations, "runtime": sysContExpectations, }), </del> <ins> "NodeName":         Equal(framework.TestContext.NodeName), "StartTime":        recent(maxStartAge), "SystemContainers": gstruct.MatchAllElements(summaryObjectID, systemContainers), </ins> "CPU": ptrMatchAllFields(gstruct.Fields{ "Time":                 recent(maxStatsAge), "UsageNanoCores":       bounded(100E3, 2E9),

Related discussion:
text: So if this is still reproducible, it's limited to 1.4. See this the bug was created for the post-fix.
Found the explanation here: The should use the flag to know the location that has the processes that are associated with , but it should not modify the cgroups of existing processes on the system during bootstrapping of the node. This is because is the on the host and it has not delegated authority to the to change how it manages .
IIUC this is intended behavior on systemd nodes. Based on the explanation provided, the kubelet doesnt have the authority to control "misc" processes on systemd.
+1. "misc" is just a bandaid for cvm. , David Ashpole <:
Ok, so I'm closing this issue.
Code change:
"errors" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/types" "k8s.io/kubernetes/pkg/volume" volumetest "k8s.io/kubernetes/pkg/volume/testing"

Related discussion:
text: When user creates a static PV using folder name in path: on vSAN backed datastore then detach disk does not work because check fails - The code expects folder name to be UUID but it does not and hence it determines disk is not attached to the node and hence no detach is ever performed. /sig storage cc
Code change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/net:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/runtime:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/typed/core/v1:go_default_library", "//staging/src/k8s.io/client-go/tools/record:go_default_library",

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I created several Workloads which require up to ten ports for both UDP and TCP protocol. Now my logs get spammed with . What you expected to happen: should consider -combination instead of only . How to reproduce it (as minimally and precisely as possible): Deploy any service with a node-port with both protocols, e.g.: Anything else we need to know?: This was already acknowledged by here: However, as this thread addresses a different bug and seems kind of stuck, i'd like to suggest that this might be addressed in a new context. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Deployed via Rancher v2.4.3
/sig api-machinery
/remove-sig api-machinery /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
How did you get into this situation? The allocator should not have granted the same node port twice?
Oh right, that issue. The only real way out is to de-allocate the NodePorts and then re-allocate them, I think
As this happens for all of my ports in the said Production Application (the one where my log gets spammed) as well as complete fresh installation (where i verified the bug), i think there's no "way out" except fixing the bug. As said, for me it's necessary to assign both protocols to the same port. This might be a niche-use-case, but checking the it's actually very likely for ports to allow tcp AND udp. I'm not sure about the history of this, but it might be that issue was the origin, which was adressed in PR ("Allow services which use same port, different protocol to use the same nodePort for both"). But this PR doesn't contain the adjustment of the said , so still considers the behaviour as invalid, while it's actually allowed and supported.
Code change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/net:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/runtime:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/typed/core/v1:go_default_library", "//staging/src/k8s.io/client-go/tools/record:go_default_library",

Related discussion:
text: /assign
Ahh, I thought you meant that you had accidentally been allocated the same nodePorts and I was very confused when you said "all of them". I have reproduced this issue, and I can see it by inspection. The obvious fix would be to collect ports split by protocol, but I think that's not right since we don't store it split. An even simpler fix would be for to build a . Then for each protocol, for each port, build that contains all the port numbers, but remove any duplicates ONLY IF they are duplicated across protocols. Duplicates in the same protocol should be retained (to report an error later). I don't have time to tackle this tonight (and write a test), but it seems like a good bug.
perhaps I can fix this problem /assign
things may be a little more complicated. Right now the is not aware of the protocol of the port so I guess simply rewriting function to return is not enough, the port allocator will still return on same node port even with different protocol. perhaps we need to refactor the to make it protocol-aware.
I don't think we need to do make the allocator be protocol aware. IIRC we allow you to use the same nodeport on different protocols ONLY within a single service. This means (I think) that we can do hyper-local deduplication as we collect the nodeports for each service. If we find the same nodeport number with different protocols, just remove the duplicates because it is allowed. I.e. a service that looks like: return - deduped. if ANY OTHER service tried to use it would be an error at the "rebuilt" allocator Likewise if a single Service claims to use the same nodeport number more than once on the same protocol, it should be an error: return - NOT deduped.
obviously, we want a great unit test here :P
ah got it! thanks for your detailed explanation!
Hi! I have filed a PR to resolve this issue, could you take a look?
Code change:
// Allow users to update labels and capacity oldMinion.Labels = minion.Labels oldMinion.Spec.Capacity = minion.Spec.Capacity <ins> // Clear status oldMinion.Status = minion.Status </ins> if !reflect.DeepEqual(oldMinion, minion) { glog.V(4).Infof("Update failed validation %#v vs %#v", oldMinion, minion)

Related discussion:
text: Two problems: on node do not have namepace, but kubectl requires namespace. However, if explicitly set namespace to 'default', this will cause an error because we are updating not allowed field (only label update is allowed). is usually created by node controller, update node label with a file is tedious since user needs to create a file with id, resource.capacity, etc. can we make it easier?
It would make more sense to have a special global namespace than no namespace. We should make it easy in kubectl to update a single field or subset of fields, generally, for all objects. What this would do is GET, merge, and PUT.
I had a discussion with on IRC about namespace on node. We'd like to just use "" (empty string) as of now. As we are not supporting any namespace feature on node, it's less confusing if we can hide the concept for now. Thinking a little more, "" is the special global namespace. I'm going to update kubectl to not assume 'default' namespace on every resources. It works fine for pod, service, but not for node, external LB, etc.
There was some discussion about "" being (essentially) an alias to "default": is that dead? , Deyuan Deng wrote:
I've seen two versions of NamespaceALL ("") NamespaceAll is the default argument to specify on a context when you want to list or filter resources across An empty namespace is equivalent to the , but "default" is the canonical representation. Either means , or the definition conflicts - all namespace should include "default" namespace. Also, for things like Node, I'd really like a NamespaceNone.
- I think there is a confusion here because of a poor naming choice. is a constant intended to be used as a filter to LIST/WATCH across multiple namespaces. It is NOT intended to be the value that is set on a resource for persistence. The discussion was to update to which I think is still a good thing to do. I have held off doing that until after we embed the namespace as a path parameter in our URLs instead of a query parameter, which I plan to look at after the holidays. is a constant intended to be used as the namespace context of a request when it's not explicitly stated on a request URL.
Code change:
// Allow users to update labels and capacity oldMinion.Labels = minion.Labels oldMinion.Spec.Capacity = minion.Spec.Capacity <ins> // Clear status oldMinion.Status = minion.Status </ins> if !reflect.DeepEqual(oldMinion, minion) { glog.V(4).Infof("Update failed validation %#v vs %#v", oldMinion, minion)

Related discussion:
text: Since create operations pull the namespace from the context during persistence, it is also the value intended to be persisted. This is referring to a request URL that does not specify a namespace. It is not referring to the persisted value in the database directly - although that is the value that gets pulled. I think a is a good thing to add AFTER we make the change to specify namespace as a path parameter instead of a query parameter, and we update/rename to something that clarifies that its a wild-card filter whose value is probably best represented as.
ok, sounds good. Thanks. Look forward to see api.NamespaceAll = "*" and api.NamespaceNone :)
Code change:
// EnvVarSource represents a source for the value of an EnvVar. // Only one of its fields may be set. type EnvVarSource struct { <del> // Selects a field of the pod: supports metadata.name, metadata.namespace, metadata.labels, metadata.annotations, </del> <ins> // Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['<KEY>']`, `metadata.annotations['<KEY>']`, </ins> // metadata.uid, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs. // +optional FieldRef *ObjectFieldSelector

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When I tried to create a pod with env variables referencing to annotations: What you expected to happen: Should Proceed. As in It stated is a valid option How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig docs
The API docs need to be updated to indicate the correct supported values. See for correct values
You are a lifesaver. Thank you!
/assign I can try to update the api documentation
Code change:
{% if grains['os_family'] == 'RedHat' -%} {% set daemon_args = "" -%} {% endif -%} <del> {% if grains.etcd_servers is defined -%} {% set etcd_servers = "-etcd_servers=http://" + grains.etcd_servers + ":4001" -%} </del> <ins> {% if grains.api_servers is defined -%} {% set api_servers = "-master=http://" + grains.api_servers + ":7080" -%} </ins> {% else -%} {% set ips = salt['mine.get']('roles:kubernetes-master', 'network.ip_addrs', 'grain').values() -%} <del> {% set etcd_servers = "-etcd_servers=http://" + ips[0][0] + ":4001" -%} </del> <ins> {% set api_servers = "-master=http://" + ips[0][0] + ":7080" -%} </ins> {% endif -%} <del> DAEMON_ARGS="{{daemon_args}} {{etcd_servers}}" </del> <ins> DAEMON_ARGS="{{daemon_args}} {{api_servers}}" </ins>

Related discussion:
text: is sent as a fix. cc It's a test failure reported by the publishing robot.
The line it fails at:
It looks like a vendor copy vs gopath copy issue.
One possible fix is removing from the vendor/ directory. I'm testing locally.
Confirmed removing from the vendor/ directory fixed the test in robot.
We need to add the "issue filer" feature to the publishing robot, we can't rely on to report robot issues everytime :P I'm just not sure how long the publishing robot will be needed (i.e., when we will get rid of the staging/ directory) so not sure whether we should invest more time on the robot.