jiebi/CodeConvo huggingface dataset:
Change:
v := version.Get() headers.Set("User-Agent", fmt.Sprintf("kube-probe/%s.%s", v.Major, v.Minor)) } <ins> if _, ok := headers["Accept"]; !ok { // Accept header was not defined. accept all headers.Set("Accept", "*/*") } if headers.Get("Accept") == "" { // Accept header was overridden but is empty. removing headers.Del("Accept") } </ins> req.Header = headers if headers.Get("Host") != "" { req.Host = headers.Get("Host")

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : I would like that besides User-agent we the Accept header as well with the "acept all" default. Just like curl does. Why is this needed: Because it was my expectation that the probe would work similarly to a curl but is not the case. I think more folks can hit this situation and waste some time to finally sort it out If this is not something you would like to add I would then like the docs to mention this specifically. _ PS: I would love to propose the improvement my self
/sig node network
/assign
Is the goal simply to avoid tripping over servers that look for that header? I don't think this presents any hazards - is that right? If so, it seems like a simple PR if you want to tackle it. /triage accepted /kind feature
cool! will look into it! thanks :)
Hello sorry but be bugging you, but I have opened the PR but I had 0 response since then. I think I have met all the requirements, so I was wondering (as this is my first PR in k8s) if you could help me a bit. Thanks anyway.
Change:
if s.Empty() { return r } <del> return r.setParam(api.FieldSelectorQueryParam(r.apiVersion), s.String()) </del> <ins> s2, err := s.Transform(func(field, value string) (newField, newValue string, err error) { return fieldMappings.filterField(r.apiVersion, r.resource, field, value) }) if err != nil { r.err = err return r } return r.setParam(api.FieldSelectorQueryParam(r.apiVersion), s2.String()) </ins> } // LabelsSelectorParam adds the given selector as a query parameter

Discussion:
My broke it for v1beta3, then fixed it for v1beta3 and broke it for v1beta1. I'm working on a fix.
Honestly I'm very surprised that more people aren't complaining-- integration test logs are full of noise because of this.
Exact text of error log is "Failed to watch *api.Node: field label not supported: "
cc
Change:
unix.Close(n.epfd) close(n.stop) } <ins> // disabledThresholdNotifier is a fake diasbled threshold notifier that performs no-ops. type disabledThresholdNotifier struct{} func (*disabledThresholdNotifier) Start(_ chan<- struct{}) {} func (*disabledThresholdNotifier) Stop()                   {} </ins>

Discussion:
Start kubelet on a cgroupv2 image with kubelet config option or the flag enabled. Kubelet will periodically log something like: This is because the kernel memcg notifications relies on kubelet's which uses evenfd on file which is cgroupv1 specific and not supported on cgroupv2. Kubelet will disable kernel memcg notifications on cgroupv2 if they are unsupported and consider long term support for more cgroupv2 "compatible" ways to monitor for memory pressure. The closest analogous cgroupv2 concept is using inotify notifications on file and or combination with PSI pressure. This requires to be set on pod cgroup which requires the MemoryQOS feature to be enabled Start kubelet on a cgroupv2 image with enabled.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node /cc
Change:
// same status. newStatus.ObservedGeneration = rs.Generation <del> var getErr error </del> <ins> var getErr, updateErr error var updatedRS *extensions.ReplicaSet </ins> for i, rs := 0, rs; ; i++ { <del> glog.V(4).Infof(fmt.Sprintf("Updating replica count for ReplicaSet: %s/%s, ", rs.Namespace, rs.Name) + </del> <ins> glog.V(4).Infof(fmt.Sprintf("Updating status for ReplicaSet: %s/%s, ", rs.Namespace, rs.Name) + </ins> fmt.Sprintf("replicas %d->%d (need %d), ", rs.Status.Replicas, newStatus.Replicas, *(rs.Spec.Replicas)) + fmt.Sprintf("fullyLabeledReplicas %d->%d, ", rs.Status.FullyLabeledReplicas, newStatus.FullyLabeledReplicas) + fmt.Sprintf("readyReplicas %d->%d, ", rs.Status.ReadyReplicas, newStatus.ReadyReplicas) +

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? dangling ReplicaSet Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure A1 OS (e.g. from /etc/os-release): NAME="Container Linux by CoreOS" ID=coreos VERSION=1235.9.0 VERSIONID=1235.9.0 BUILDID=2017-02-02-0235 PRETTYNAME="Container Linux by CoreOS 1235.9.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" Kernel (e.g. ): Linux node-3-vm 4.7.3-coreos-r2 SMP Thu Feb 2 02:26:10 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: own Others: What happened: Created new deployment by altering the image tag of the deployment descriptor and using kubectl apply -f "". Noticed that one container of the previous deployment stayed there. What you expected to happen: All containers from the previous deployment should have been terminated. How to reproduce it (as minimally and precisely as possible): I cannot reliably trigger this, I do several deployments per hour and sometimes this problem manifests itself. Anything else we need to know: Deployment descriptor:
Can you also post the output of kubectl get deployment tviftttapp -o yaml kubectl get rs (dangling rs) -o yaml When this manifests again?
Here are the current deployment, the dangling RS, and the "good" RS. Deployment: Dangling RS: Current RS:
It seems that status.availableReplicas for the new replica set is never correctly updated to 2. Short term if you stop using minReadySeconds (minReadySeconds=2 doesn't offer you much anyway), this problem should stop. Long term, we should fix the status update. cc:
can one of you guys paste logs from the controller manager when this issue occurs? Log level should be ideally set to 2.

I managed to reproduce it:
Will close this one once is cherry-picked into 1.5
4 is out and contains a fix that should force the Deployment to be resynced eventually and have availableReplicas updated. Not optimal yet but eventually consistent. I have queued up some follow-up work to refine the resync.
Does anyone know when version 1.5.4 OR 1.6 will be available using Redhat package downloads (in RPM form) ? I only see version 1.5.2 being the latest there. I have the same problem that is being discussed in this thread and want to upgrade so that my K8S cluster can support Deployments.
Change:
} fakeDocker.containerList = []docker.APIContainers{ { <del> // the '--' is required for the kubelet to manage the container Names: []string{"foo--bar"}, </del> <ins> // the k8s prefix is required for the kubelet to manage the container Names: []string{"/k8s--foo--bar"}, </ins> ID:    "1234", }, { // network container <del> Names: []string{"k8snet--foo--"}, </del> <ins> Names: []string{"/k8s--net--foo--"}, </ins> ID:    "9876", }, {

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)
Change:
client := clientValue.Load().(*clientv3.Client) ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel() <del> // See https://github.com/etcd-io/etcd/blob/master/etcdctl/ctlv3/command/ep_command.go#L118 _, err := client.Get(ctx, path.Join(c.Prefix, "health")) </del> <ins> // See https://github.com/etcd-io/etcd/blob/c57f8b3af865d1b531b979889c602ba14377420e/etcdctl/ctlv3/command/ep_command.go#L118 _, err := client.Get(ctx, path.Join("/", c.Prefix, "health")) </ins> if err == nil { return nil }

Discussion:
<!-- 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: apiserver fails to pass readiness/liveness check when we upgrade k8s 1.12 to k8s.14+. there are some detail error messages in apiserver when we increase log level to 6(healthz check etcd failed: error getting data from etcd: etcdserver: permission denied.) our etcd cluster grant specified prefix(for example,/cluster-1) permission to k8s cluster. there is no problem in k8s1.12. etcd healthz check is implemented by getting prefix+'/'+health path in k8s 1.14+,but prefix do not join '/'. there is no problem in etcd3 store, pathPrefix is joined by '/' and prefix. What you expected to happen: prefix joins '/' in etcd healthz check.
/sig api-machinery
/assign
GitHub didn't allow me to assign the following users: jingyih. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
What custom etcd prefix are you passing in? if you prefix it with , that should resolve this issue for you in the short-term. I agree the health check key prefix should be computed the same way as the etcd client prefix
thanks. yes, we prefix it with '/' to resolve this issue.
Change:
- apiGroups: ["extensions", "networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch"] <del> # For now, GLBC annotates ingress resources with various state and statuses: </del> <ins> # For now, GLBC annotates ingress resources with various state and statuses: </ins> # https://github.com/kubernetes/ingress-gce/blob/50d49b077d9ab4362a02fae05f94e433cd3f08dc/pkg/controller/controller.go#L579 # TODO(rramkumar1): Remove unnecessary `update` permission once statuses are propagated through `ingresses/status` - apiGroups: ["extensions", "networking.k8s.io"]

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: Since when has it been failing: The full testgrid history is red, but it has been failing at least since 5/29 Testgrid link: Reason for failure: Anything else we need to know: Originally these failures were due to an rbac permission issue (see: ), but now that that has been resolved, the tests are still not passing.
/sig network
adding to the milestone for investigation, since ingress was touched this release /milestone v1.19
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
what is the difference between that job and (which seems to be mostly passing)?
/assign
Also assigning since I think he's already looking into this: /assign
Oh nice, prow can actually assign me now
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Sorry for the delay. This has been triaged. The actual issue is that: system:controller:glbc rbac needs patch permissions for "ingresses/status" in I will send a PR for the fix. /remove-triage unresolved
^ PR
looks like that resolved almost all the failures. is still failing
Nice! Looks like this failure is caused by relying on the old static IP behavior. We used to allocate one if the specified one did not exist. I will send a PR to update the test.
can we close this out with ?
Yes, latest run was green:
/reopen Can this be reviewed again please? cc
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
seems to be a RBAC issue?
/cc did ingress-gce just start expecting access to this resource recently? does the RBAC role at need to be updated?
Hi, I've filed to address the issue.
Change:
// the http.ResponseWriter. We can recover panics from go-restful, and // the logging value is questionable. type respLogger struct { <del> hijacked           bool statusRecorded     bool status             int statusStack        string </del> <ins> hijacked       bool statusRecorded bool status         int statusStack    string // mutex is used when accessing addedInfo and addedKeyValuePairs. // They can be modified by other goroutine when logging happens (in case of request timeout) mutex              sync.Mutex </ins> addedInfo          strings.Builder addedKeyValuePairs []interface{} startTime          time.Time captureErrorOutput bool <del> req *http.Request w   http.ResponseWriter </del> <ins> req       *http.Request userAgent string w         http.ResponseWriter </ins> logStacktracePred StacktracePred }

Discussion:
Apiserver crashed with stacktrace: Not to crash I was able to reproduce it by "slowing down" deleting headers in Authentication filter (): And making requests (around 5-10 requests to trigger this race condition): Crash was caused by race condition - one goroutine was modifying headers of requests (for example authentication filter). The other goroutine was trying to get UserAgent from request, which is also taken from request's headers map. This causes unrecoverable panic. <detailsAll versions, tested on 1.21 </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /priority important-soon
/triage accepted
Reopening - since we need to cherrypick it to previous releasses.
- friendly ping on opening cherrypicks
I've opened two cherry-picks:
One more for 1.20:
All merged - thanks!
Change:
{% set auth_path = "-auth_path=/var/lib/kubelet/kubernetes_auth" -%} <ins> {% set registry_qps = "-registry_qps=0.1" %} </ins> DAEMON_ARGS="{{daemon_args}} {{etcd_servers}} {{apiservers}} {{auth_path}} {{hostname_override}} {{address}} {{config}} --allow_privileged={{pillar['allow_privileged']}}"

Discussion:
introduces PullPolicies (PullAlways, PullNever, PullIfNotPresent), but by default, the policy is PullAlways, which bite docker repository again today. The related #google-containers IRC conversation can be found at: We should Introduce a new policy to cap the number of attempts. Maybe getting rid of PullAlways completely? cc/
I would like to change the default one to PullIfNoPresent for now. We can continue discussing the right policies.
Suggestions: PullIfNotPresent should be our default? PullAlways needs to be nerfed. Suggestion: max N pull attempts per pod config change, with <attempt#*10 second delay between each pull attempt, where N is a small number like 3 or 5.
I think both PullIfNotPresent and PullAlways (if we decide to still have it) should be nerfed.
Agreed, when "not present", we should behave the same as PullAlways, which should be nerfed.
Not finding another issue, so recording here for posterity: we really need a TTL on images to make PullIfNotPresent maximally useful.
So if a registry is down and the cluster restarts, pods will eventually give up (if we're nerfing pull always)? Seems like we should drastically reduce pull frequency after failures, but giving up means you can get into weird various scenarios. Esp if the registry is hosted in the cluster. Why not just back off?
I vote for some exponential back off. , Clayton Coleman wrote:
We think we do have backoff now, check and close it if so.
Change:
nodeStatusUpdateFrequency: nodeStatusUpdateFrequency, } <del> nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: cnc.AddCloudNode, </del> <ins> // Use shared informer to listen to add/update of nodes. Note that any nodes // that exist before node controller starts will show up in the update method cnc.nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc:    cnc.AddCloudNode, UpdateFunc: cnc.UpdateCloudNode, </ins> }) return cnc

Discussion:
Once cloud-controller-manager is started we should remove the taint. right?
/sig cluster-lifecycle
/area cloudprovider do you have anymore information on this? I can't reproduce this on existing nodes before the CCM was created or new nodes to a cluster.
i can recreate this using by setting along with a CLOUDCONFIG + CLOUDPROVIDER env vars
If you're running a local cluster then how are you running the CCM? The only way the taint gets removed is if the instance was found in the cloud provider and setup (labels, addresses, etc) OK. The code can be found
the local cluster is started within a openstack vm. so it's a one vm cluster. thanks for the pointer, will check it out
/assign
- So ... when i use local-up-cluster, the kubelet starts up before the cloud-controller-manager. So the shared informer that calls is never triggered. This patch seems to fix the issue. Note that RBAC stuff needed to be setup for as well for the to succeed.
Change:
NewSourceFile("random_non_existent_path", time.Millisecond, ch) select { case got := <-ch: <del> t.Errorf("Expected no update, Got %#v", got) </del> <ins> update := got.(kubelet.PodUpdate) expected := CreatePodUpdate(kubelet.SET, kubelet.FileSource) if !api.Semantic.DeepEqual(expected, update) { t.Fatalf("Expected %#v, Got %#v", expected, update) } </ins> case <-time.After(2 * time.Millisecond): <ins> t.Errorf("Expected update, timeout instead") </ins> } }

Discussion:
To reproduce: Start a cluster via hack/local-up- Start some pods Kill the cluster "docker ps -a" should show the pod containers running still Start the cluster again "etcdctl ls /registry" should show that there is no boundpods directory -- only minions and services "docker ps -a" should show the old pod containers still running Start a new pod After, say, 10s, "docker ps -a" should show the old containers dead /cc
I suspect the cause of this might be : which guarantees that the pod sync logic is never called if is nil. Need to get a repro to confirm.
Change:
if nodeInfo == nil { return nil, 0, false } <del> potentialVictims := util.SortableList{CompFunc: util.HigherPriorityPod} </del> <ins> potentialVictims := util.SortableList{CompFunc: util.MoreImportantPod} </ins> nodeInfoCopy := nodeInfo.Clone() removePod := func(rp *v1.Pod) {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When selecting victims on node in (), take pod's into account. When two pod's Priority is equal, preempt pod whose is later first. Why is this needed: If a pod's has been running for a longer time, it might finish earlier, or it might have done more things. It might make more sense to preempt them later, e.g. a user submitted a job A at time 9:00 am, then he submitted a job B at time 10:00 am, he might expect that scheduler preempts pods for job B first. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/sig scheduling /assign cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
PR implements this feature. We are currently in code freeze for 1.14. The feature will be in 1.15.
Thanks for it. It is similar with a little difference, the PR aims to select a node, and this issue aims to pick a pod whose StartTime is latter after the node has been selected.
I just sent a PR for it. PTAL :)
Change:
} for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { <del> if got := fileExists(tt.filename); got != tt.want { </del> <ins> if got, _ := fileExists(tt.filename); got != tt.want { </ins> t.Errorf("fileExists() = %v, want %v", got, tt.want) } })

Discussion:
When the command is run with superuser privileges, it prints the requested information. Print a warning that files could not be read due to insufficient permission, or that information was missing (e.g., when the /etc/kubernetes directory is not initialized). When the directory is readable, it works as expected: where OS and kubeadm version detail was: Issue the command as a normal user when the directory /etc/kubernetes/pki exists but not readable. No response <details</details<detailsBare metal </details<details</details<detailsapt-get install kubeadm (source repo: ) </details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle