jiebi/CodeConvo huggingface dataset:
Code change:
job.Spec.Template.Spec.RestartPolicy = v1.RestartPolicyOnFailure sharedInformerFactory.Batch().V1().Jobs().Informer().GetIndexer().Add(job) podIndexer := sharedInformerFactory.Core().V1().Pods().Informer().GetIndexer() <del> for i, pod := range newPodList(int32(len(tc.restartCounts)), v1.PodRunning, job) { </del> <ins> for i, pod := range newPodList(int32(len(tc.restartCounts)), tc.podPhase, job) { </ins> pod.Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: tc.restartCounts[i]}} podIndexer.Add(&pod) }

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 create a job with initcontainer with restartPolicy : when the initContainer exec failed and it will be restarted, the pod Phase will be pending all the time. but in JobController, the only care the running pod. So this pod will be always restarted. What you expected to happen: when restart count to backoffLimit, the job failed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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 apps
/assign
Code change:
"Logs":               BeNil(), "UserDefinedMetrics": BeEmpty(), }) <ins> systemContainers := gstruct.Elements{ "kubelet": sysContExpectations, "runtime": sysContExpectations, } // The Kubelet only manages the 'misc' system container if the host is not running systemd. if !systemdutil.IsRunningSystemd() { framework.Logf("Host not running systemd; expecting 'misc' system container.") systemContainers["misc"] = sysContExpectations } </ins> // Expectations for pods. podExpectations := gstruct.MatchAllFields(gstruct.Fields{ "PodRef":    gstruct.Ignore(),

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:
"Logs":               BeNil(), "UserDefinedMetrics": BeEmpty(), }) <ins> systemContainers := gstruct.Elements{ "kubelet": sysContExpectations, "runtime": sysContExpectations, } // The Kubelet only manages the 'misc' system container if the host is not running systemd. if !systemdutil.IsRunningSystemd() { framework.Logf("Host not running systemd; expecting 'misc' system container.") systemContainers["misc"] = sysContExpectations } </ins> // Expectations for pods. podExpectations := gstruct.MatchAllFields(gstruct.Fields{ "PodRef":    gstruct.Ignore(),

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:
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object <del> // EncryptionConfiguration stores the complete configuration for encryption providers. </del> <ins> /* EncryptionConfiguration stores the complete configuration for encryption providers. example: kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets - configmaps - pandas.awesome.bears.example providers: - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== */ </ins> type EncryptionConfiguration struct { metav1.TypeMeta // resources is a list containing resources, and their corresponding encryption providers.

Related discussion:
text: Update the godoc on the encryption config API on how to specify group/resources to be encrypted ref: godoc has the details na No response_ na na <details</details<details</details<details</details<details</details
/sig auth /triage accepted
/assign Cool-Coder174
Thanks for volunteering for this LMK if you need any help with it.
Just for clarification, I just need to add documentation on how to configure encryption on groups/resources?
You can update godoc to mention that custom resources can now be to the list of to be encrypted as well and how to add the of the resource to the list. e.g. from this test
/assign /unassign Release v1.26 deadlines are here so we need to get this completed ASAP.
/milestone v1.26
I apologize for the slow actions. I know time and contributions are valuable. May I request a walk through. This is my first time ever contributing and I really want to learn. I have been reading some of the code base on my spare time.
this feature is on the harder side of things to get started with. Reading the blog post and the associated documentation is probably the best starting point:
& what is the status on this issue? 1.26 is coming up! cc
/milestone v1.27
Code change:
import ( "fmt" <ins> "net/http/httptest" </ins> "testing" "k8s.io/kubernetes/pkg/api"

Related discussion:
text: The test is in flaky suite and no one seems to care. We need an owner for this test. cc Last failure log:
do you think you can take a look at this?
This is happening because of a bad assumption. The assumption is: if the reflector's store is consistent with etcd, the store given back to clients of the framework.Controller is too. I'd really like a general fix applicable to all controllers for this problem, but fixing it just for the RCs is pretty easy. In more detail: This function reports when the reflector has listed from apiserver. But the store given to the reflector is the fifo of the framework.Controller. The store given back to the caller is still not consistent, and will not be till the framework.Controller puts all the objects from the fifo into the client state store (). The rc specific fix: Before starting the rc manager, seed the expectations store with an expectation like {rc:foo, adds: foo.Status.Replicas, deletes:0}. This will wait for status.Replicas number of ADD events till a timeout. The general fix: Somehow expose this through framework.Controller.HasSynced (clients don't care about the fifo anyway, shouldn't it just be an implementation detail?) ideas? cc'ing people who have written controllers that might be interested I don't think this (and generally anything flaky for 1 release) is a p0, I can fix it if you don't mind dealing with the flakes till I've cleared things off my plate. I'd be more than happy to review a fix.
Well, it's a P0 because test is flaky. E.g last run:
- did you have chance to look into it?
The "DaemonRestart" tests are still labeled at . I will send a PR to promote them.
are you still planning to send aPR to promote the DaemonRestart tests out of flaky? I think this is the right thing to do.
Ack; sorry, I lost this in the muck.
Code change:
./hack/test-cmd.sh ./hack/test-integration.sh ./hack/test-update-storage-objects.sh

Related discussion:
text: Not sure if this concided with a Jenkins restart.
Not sure what we can do about this. Retry a few times?
GitHub seemed to hiccup last night and fail a bunch of our builds. I'm not sure a retry would've helped, unless we kept retrying for many minutes.
This is the sort of thing that just happens occasionally. We've seen this a lot in OpenShift CI runs. I'm not sure there's much you can do other than try to avoid external network access (e.g. bake tools into the VM image).
It seems to have occurred twice in the last 12h so retry w/ timeout can't hurt?
It can't hurt... but it may or may not help depending on the extent of the external issue
If the problem is really bad, we could toss it somewhere on GCS?
Looks like it failed on : We should probably put this in a retry loop or else do something more fancy
Code change:
klog.Errorf("scheduler cache AddNode failed: %v", err) } <ins> klog.V(3).Infof("add event for node %q", node.Name) </ins> sched.SchedulingQueue.MoveAllToActiveOrBackoffQueue(queue.NodeAdd) }

Related discussion:
text: This helps debugging scheduler's behavior, currently we don't have logs that indicate when the scheduler first saw a pod or a node. The log level should be v=3. /sig scheduling /cc
Do you mean add logging for callbacks in ?
yes, at least for add and delete events
Sure, I can also give this pr, before tomorrow
/assign
We actually have one v=2 log line for a Node being to the cache's tree: But it's probably good to keep this one.
Code change:
} func (kvh *kubeletVolumeHost) GetPodVolumeDir(podUID types.UID, pluginName string, volumeName string) string { <del> return kvh.kubelet.getPodVolumeDir(podUID, pluginName, volumeName) </del> <ins> dir := kvh.kubelet.getPodVolumeDir(podUID, pluginName, volumeName) if runtime.GOOS == "windows" { dir = volume.GetWindowsPath(dir) } return dir </ins> } func (kvh *kubeletVolumeHost) GetPodVolumeDeviceDir(podUID types.UID, pluginName string) string {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have tried FlexVolume on a Windows node, it does not work. I am now working on this feature now. Below is the FlexVolume initialization error What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.7.7 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows /assign
Detailed steps about how to use flexvolume on Windows with this PR:
cc:
Code change:
// TestTimeout is used for most polling/waiting activities TestTimeout = 60 * time.Second <ins> // AffinityTimeout is the maximum time that CheckAffinity is allowed to take; this // needs to be more than long enough for AffinityConfirmCount HTTP requests to // complete in a busy CI cluster, but shouldn't be too long since we will end up // waiting the entire time in the tests where affinity is not expected. AffinityTimeout = 2 * time.Minute </ins> // AffinityConfirmCount is the number of needed continuous requests to confirm that // affinity is enabled. AffinityConfirmCount = 15

Related discussion:
text: Which jobs are failing: pull-kubernetes-e2e-gce Which test(s) are failing: [sig-network] Services should have session affinity work for NodePort service [LinuxOnly] [sig-network] Services should be able to switch session affinity for service with type clusterIP [LinuxOnly] [sig-network] Services should be able to switch session affinity for NodePort service [LinuxOnly] [sig-network] Services should have session affinity work for service with type clusterIP [LinuxOnly] Since when has it been failing: At least since 9/30 (). But that's almost at the end of what's currently visible on the testgrid, so maybe longer Testgrid link: Not sure what I'm supposed to put here. ? Reason for failure: The test case connects to a service every 2 seconds for 1 minute and checks if it hit the same endpoint at least 15 times in a row. But the individual checks are taking unexpectedly long and so sometimes the test doesn't even manage to run 15 times total in 1 minute.
Code change:
// TestTimeout is used for most polling/waiting activities TestTimeout = 60 * time.Second <ins> // AffinityTimeout is the maximum time that CheckAffinity is allowed to take; this // needs to be more than long enough for AffinityConfirmCount HTTP requests to // complete in a busy CI cluster, but shouldn't be too long since we will end up // waiting the entire time in the tests where affinity is not expected. AffinityTimeout = 2 * time.Minute </ins> // AffinityConfirmCount is the number of needed continuous requests to confirm that // affinity is enabled. AffinityConfirmCount = 15

Related discussion:
text: eg: Oct 8 13:32:01.402: INFO: Running ' --server=https://34.82.143.14 -- exec --namespace=services-1060 execpod-affinityklpfn -- /bin/sh -x -c curl -q -s --connect-timeout 2 http://10.40.0.5:/' Oct 8 13:32:07.627: INFO: stderr: "+ curl -q -s --connect-timeout 2 http://10.40.0.5:/n" Oct 8 13:32:07.627: INFO: stdout: "affinity-nodeport-2z9hv" Oct 8 13:32:07.627: INFO: Received response from host: affinity-nodeport-2z9hv Oct 8 13:32:09.402: INFO: Running ' --server=https://34.82.143.14 -- exec --namespace=services-1060 execpod-affinityklpfn -- /bin/sh -x -c curl -q -s --connect-timeout 2 http://10.40.0.5:/' Oct 8 13:32:16.027: INFO: stderr: "+ curl -q -s --connect-timeout 2 http://10.40.0.5:/n" Oct 8 13:32:16.027: INFO: stdout: "affinity-nodeport-2z9hv" Oct 8 13:32:16.027: INFO: Received response from host: affinity-nodeport-2z9hv Note the gap between the "Running" line and the "stderr" line. It's not clear if the slowness is in connecting to the execpod or in connecting from the execpod to the affinity service. It is also not particularly consistent between attempts. (Here it was 6s, 1s, 2s, 3s, 5s, 7s, 7s, 3s, 4s, 6s, 7s, 8s.) Anything else we need to know: It looks the checks are also slow in successful runs, it's just that they're not quite as slow, so they pass.
Code change:
// TestTimeout is used for most polling/waiting activities TestTimeout = 60 * time.Second <ins> // AffinityTimeout is the maximum time that CheckAffinity is allowed to take; this // needs to be more than long enough for AffinityConfirmCount HTTP requests to // complete in a busy CI cluster, but shouldn't be too long since we will end up // waiting the entire time in the tests where affinity is not expected. AffinityTimeout = 2 * time.Minute </ins> // AffinityConfirmCount is the number of needed continuous requests to confirm that // affinity is enabled. AffinityConfirmCount = 15

Related discussion:
text: I'm not sure if the problem is "something is making the cluster slow and so this totally valid test is taking too long and failing" or "e2e-gce has grown over time and now cluster load has reached the point where this formerly-passing test now has unreasonable performance expectations". /sig network
Code change:
return &runtimeapi.UpdateContainerResourcesResponse{}, nil } <del> func (ds *dockerService) performPlatformSpecificContainerForContainer(containerID string) { </del> <ins> func (ds *dockerService) performPlatformSpecificContainerForContainer(containerID string) (errors []error) { </ins> if cleanupInfo, present := ds.containerCleanupInfos[containerID]; present { <del> ds.performPlatformSpecificContainerCleanupAndLogErrors(containerID, cleanupInfo) delete(ds.containerCleanupInfos, containerID) </del> <ins> errors = ds.performPlatformSpecificContainerCleanupAndLogErrors(containerID, cleanupInfo) if len(errors) == 0 { delete(ds.containerCleanupInfos, containerID) } </ins> } <ins> return </ins> } <del> func (ds *dockerService) performPlatformSpecificContainerCleanupAndLogErrors(containerNameOrID string, cleanupInfo *containerCleanupInfo) { </del> <ins> func (ds *dockerService) performPlatformSpecificContainerCleanupAndLogErrors(containerNameOrID string, cleanupInfo *containerCleanupInfo) []error { </ins> if cleanupInfo == nil { <del> return </del> <ins> return nil </ins> } <del> for _, err := range ds.performPlatformSpecificContainerCleanup(cleanupInfo) { </del> <ins> errors := ds.performPlatformSpecificContainerCleanup(cleanupInfo) for _, err := range errors { </ins> klog.Warningf("error when cleaning up after container %q: %v", containerNameOrID, err) } <ins> return errors </ins> }

Related discussion:
text: What would you like to be : Periodically remove cleanupInfos for old containers from dockershim's map. One way of doing that would be to just forget about s older than say an hour, as they should always be short-lived. Why is this needed: introduced a new in-memory map for the dockershim, that could potentially (in pathological cases) cause memory leaks - for containers that use GMSA cred specs, get created successfully, but then never get started nor removed. This might be okay for the alpha release of the GMSA feature, but should be addressed in the beta. See
/assign wk8
/sig windows
/milestone v1.15
got moved out. let's move this issue with it as well /milestone v1.16
Hello! I'm bug triage lead for the 1.16 release cycle and considering this issue is tagged for 1.16, but not updated for a long time, I'd like to check its status. The code freeze is starting on August 29th (about 1.5 weeks from now), which means that there should be a PR ready (and merged) until then. Do we still target this issue to be fixed for 1.16?
: yup we'd love to have this in 1.16, still waiting for kind reviewers on :) ...
Code change:
import ( "fmt" "net" <ins> "runtime" </ins> "github.com/golang/glog"

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have tried FlexVolume on a Windows node, it does not work. I am now working on this feature now. Below is the FlexVolume initialization error What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.7.7 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows /assign
Detailed steps about how to use flexvolume on Windows with this PR:
cc:
Code change:
# define the IP range used for flannel overlay network, should not conflict with above SERVICE_CLUSTER_IP_RANGE export FLANNEL_NET=${FLANNEL_NET:-172.16.0.0/16} <ins> # Optionally add other contents to the Flannel configuration JSON # object normally stored in etcd as /coreos.com/network/config.  Use # JSON syntax suitable for insertion into a JSON object constructor # after other field name:value pairs.  For example: # FLANNEL_OTHER_NET_CONFIG=', "SubnetMin": "172.16.10.0", "SubnetMax": "172.16.90.0"' export FLANNEL_OTHER_NET_CONFIG FLANNEL_OTHER_NET_CONFIG='' </ins> # Admission Controllers to invoke prior to persisting objects in cluster export ADMISSION_CONTROL=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,SecurityContextDeny

Related discussion:
text: and provide for configuring Flannel's parameter but none of the others listed in
Code change:
return nil } <del> // DeleteTCPLoadBalancer is an implementation of TCPLoadBalancer.DeleteTCPLoadBalancer. func (gce *GCECloud) DeleteTCPLoadBalancer(name, region string) error { </del> <ins> // EnsureTCPLoadBalancerDeleted is an implementation of TCPLoadBalancer.EnsureTCPLoadBalancerDeleted. func (gce *GCECloud) EnsureTCPLoadBalancerDeleted(name, region string) error { </ins> op, err := gce.service.ForwardingRules.Delete(gce.projectID, region, name).Do() if err != nil && isHTTPErrorCode(err, http.StatusNotFound) { glog.Infof("Forwarding rule %s already deleted. Continuing to delete target pool.", name)

Related discussion:
text: All of our external load balancer tests failed for the better part of a day due to the GCE project that our tests run in hitting its quota for number of target pools. While the target pools have been deleted, the fact that we hit our quota indicates that there must be a leak somewhere, and we need to plug it.
For reference, the previous issue was
Could the leakage be related to ? The quota exhaustion occurred about 22 hrs after that.
I'd guess that this is due to GetTCPLoadBalancer returning that the load balancer doesn't exist if the forwarding rule is gone, ignoring the target pool, while the service controller considers its deleting done if the cloud provider says that the load balancer doesn't exist. I that logic to the cloud provider because the other implementations of DeleteTCPLoadBalancer weren't/won't be idempotent in the sense of returning ok if the LB doesn't exist. To fix it, we'll either need to make sure all Delete implementations are idempotent and remove the Get call in the controller, or add a method along the lines of IsTCPLoadBalancerDeleted to ask the cloud provider whether all pieces of it have been completely cleaned up. We can't make GetTCPLoadBalancer check that because it's relied on to tell us whether or not the balancer is fully created.
Copying over my commentary from on why the GKE e2e tests are leaking so many forwarding rules and target pools vs the GCE tests:
Is there a way for the services test to wait for the service controller to clean up the external resources before finishing (without just doing a sleep)?
Not without polling GCE directly for whether the resources still exist, although that may be worth it as a workaround. What would be perfect is that clean-up-all-cloud-provider-resources API method that we talked about a couple months ago.
Can we not perhaps use GCE namespaces or projects as a cheap way of getting this here?
I don't believe so. We can't use projects due to the fact that projects can't be programatically created (they're intended to be long-lived). I'm not aware of anything along the lines of a GCE namespace other than networks, which won't work because target pools and forwarding rules unfortunately don't seem to be scoped to networks.