jiebi/CodeConvo huggingface dataset:
Change:
### **Main Steps** #### I. Make *kubernetes* , *etcd* and *flanneld* binaries <del> First clone the kubernetes github repo, `$ git clone git@github.com:GoogleCloudPlatform/kubernetes.git` </del> <ins> First clone the kubernetes github repo, `$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git` </ins> then `$ cd kubernetes/cluster/ubuntu`. Then run `$ ./build.sh`, this will download all the needed binaries into `./binaries`.

Discussion:
In the step 1) of docs Clone repo kubernetes via ssh would fail: Better to change it to the .
hello, I am not the owner of k8s, but I can clone vis ssh. Maybe it's your github key issue.
In any case, the docs generally tell us to use https or so I've opened a PR to change it to https. Edit: Though I also have no issue with using ssh, it clones just fine.
Hmm so I've just tested this from a computer that has not previously interacted with github (a little debian server). It fails similarly when cloning over ssh, giving the same output as reported by We should still probably switch the docs to https.
Change:
finalPods := int32(math.Ceil(resourcesUsedRatio * float64(startPods))) // To breach tolerance we will create a utilization ratio difference of tolerance to usageRatioToleranceValue) <del> tc := testCase{ </del> <ins> tc1 := testCase{ </ins> minReplicas:             0, maxReplicas:             1000, initialReplicas:         startPods,

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!--What happened: Resync period for HorizontalPodAutoscaler controller is set to 15 seconds in order to update HPAs every 15 seconds. Sometimes updates are skipped and period between two updates is 30 seconds. What you expected to happen: HPA should be updated every 15 seconds. How to reproduce it (as minimally and precisely as possible): Add debugs to HPA controller showing how often HPAs are processed. Create HPA. Anything else we need to know?: HPA controller uses rate RateLimitingQueue: New requests are always with 15 seconds delay: If request for the given HPA is in the queue then newly request is skipped. Requests are and removed from the queue at the same moment so there is a race condition. See following scenario: 00:00:00 - Resync adds request to queue to be executed at 00:00:15 00:00:15 - Resync adds next request to queue to be executed at 00:00:30 but it is skipped because previous request is still in the queue 00:00:15 - Request at 00:00:00 is executed 00:00:30 - Resync adds next request to queue to be executed at 00:00:45 00:00:45 - Request at 00:00:30 is executed In above scenario HPA wasn't updated between 00:00:15 and 00:00:45. Environment: Kubernetes version (use ): HEAD Cloud provider or hardware configuration: GKE <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig autoscaling
/assign krzysztof-jastrzebski
Change:
labels: k8s-app: kube-dns annotations: <del> seccomp.security.alpha.kubernetes.io/pod: 'docker/default' </del> <ins> seccomp.security.alpha.kubernetes.io/pod: 'runtime/default' </ins> spec: priorityClassName: system-cluster-critical serviceAccountName: coredns

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Apply security best practices for both kube-dns and core-dns. Low hanging fruit: [x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities[x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities This is based on the long term issue and implemented by PR . Why is this needed: Our system pods should run using security best practices, both to enhance cluster security and serve as examples of best practices to users.
/sig auth /area security
Change:
trigerWatchEventTime time.Duration initAttachErr        *storage.VolumeError finalAttachErr       *storage.VolumeError <del> sleepTime            time.Duration </del> timeout              time.Duration shouldFail           bool }{ { name:         "attach success at get", initAttached: true, <del> sleepTime:    10 * time.Millisecond, </del> timeout:      50 * time.Millisecond, shouldFail:   false, }, { name:          "attachment error ant get", initAttachErr: &storage.VolumeError{Message: "missing volume"}, <del> sleepTime:     10 * time.Millisecond, </del> timeout:       30 * time.Millisecond, shouldFail:    true, },

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
return err } <del> // Do not cascade deletion for overlapping deployments. // A Deployment with this annotation will not create or manage anything, // so we can assume any matching ReplicaSets belong to another Deployment. if len(deployment.Annotations[deploymentutil.OverlapAnnotation]) > 0 { return deployments.Delete(name, nil) } </del> // Stop all replica sets belonging to this Deployment. rss, err := deploymentutil.ListReplicaSetsInternal(deployment, func(namespace string, options metav1.ListOptions) ([]*extensions.ReplicaSet, error) {

Discussion:
The Deployment overlap annotation () is no longer populated nor used by 1.6+ on the server side. However, in we maintained knowledge of the annotation for 1.6 clients in case they talk to pre-1.6 servers. That PR also adds code to clean up the annotation whenever it's found in 1.6+ clusters, so that pre-1.6 clients don't see it and make the wrong assumptions. The code handling this annotation should be removed when all the following conditions are met: We no longer support a 1.5.x client talking to the latest server version. We no longer support upgrading the server directly from 1.5.x to the latest version. The soonest milestone that meets both conditions according to the is v1.8. This issue should be moved to that milestone once it exists.
TODOs: [x] deployment controller: [x] deployment util: [x] deployment reaper: [x] deployment describer:
I can help on this
/assign
GitHub didn't allow me to assign the following users: wanghaoran1988. Note that only can be assigned. <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
thanks, feel free to send patches
Change:
// and then use the same here devsLen := int64(2) var devicePluginPod, dptemplate *v1.Pod <ins> var v1alphaPodResources *kubeletpodresourcesv1alpha1.ListPodResourcesResponse var v1PodResources *kubeletpodresourcesv1.ListPodResourcesResponse var err error </ins> ginkgo.BeforeEach(func() { ginkgo.By("Wait for node to be ready") gomega.Eventually(func() bool {

Discussion:
Device Plugin [Feature:DevicePluginProbe][NodeFeature:DevicePluginProbe][Serial] DevicePlugin [Serial] [Disruptive] Can schedule a pod that requires a device It appears a bit flaky on testgrid, but more recently been failing more often No response example - No response /sig node
/cc
/triage accepted /assign /priority important-soon
I ran this test locally 15 times back to back and did not run into this failure. The test passed locally. I suspect this to be a case where pod cleanup is not happening properly. In this test, we are relying on the number of PodResources and based on the error it looks like we have an addtional pod running other than the two expected pods (device plugin pod and test pod requesting device) but can't be 100% sure because we don't have enough logs to support that claim. Going to add more logs to expose output obtained from the podresource API endpoint.
Change:
fi popd >/dev/null <ins> if [ "${golangci_config}" ]; then # The relative path to _output/local/bin only works if that actually is the # GOBIN. If not, then we have to make a temporary copy of the config and # replace the path with an absolute one. This could be done also # unconditionally, but the invocation that is printed below is nicer if we # don't to do it when not required. if grep -q 'path: ../_output/local/bin/' "${golangci_config}" && [ "${GOBIN}" != "${KUBE_ROOT}/_output/local/bin" ]; then kube::util::ensure-temp-dir patched_golangci_config="${KUBE_TEMP}/$(basename "${golangci_config}")" sed -e "s;path: ../_output/local/bin/;path: ${GOBIN}/;" "${golangci_config}" >"${patched_golangci_config}" golangci_config="${patched_golangci_config}" fi golangci+=(--config="${golangci_config}") fi </ins> cd "${KUBE_ROOT}" res=0

Discussion:
This is a subset of "make verify doesn't work under anymore" xref: In two places we assume the path for "local builds" But when dockerized it will be at should work.
I'm not sure what the cleanest solution is here. Maybe a symlink in a fixed location that we update to point to whichever we just built ...
cc
Can we set env variables as part of ? golangci-lint doesn't support a search path for plugins yet, but perhaps that can be .
Bit of a blunt instrument but we could do that. Another blunt approach would be picking some unused path under _output to add a symlink to either I guess.
It would be really nice if we could just pass searchpaths for the plugins instead of having to pass a complete path.
relative paths are resolved relative to the config file, so you can indirectly change a root path on a fixed file by using different config paths and not have to edit the file contents ... we could use two symlinks in _output to the actual config file. Still not ideal.
This is one of the few remaining verify scripts that doesnt work on mac or otherwise dockerized.
Let's fix this by making the path absolute in a temporary copy of the golangci-lint config file: Syncing .git is relevant for testing PRs, but it seems that already ensured that it is available.
That sounds reasonable. Yeah, while working on that issue I found the other handful of verify scripts that are also broken when containerized for reasons unrelated to git. This is one of them, the others are linked in
Change:
dnsPolicy: Default containers: - name: fluentd-cloud-logging <del> image: gcr.io/google_containers/fluentd-gcp:1.34 </del> <ins> image: gcr.io/google_containers/fluentd-gcp:1.35 </ins> # If fluentd consumes its own logs, the following situation may happen: # fluentd fails to send a chunk to the server => writes it to the log => # tries to send this message to the server => fails to send a chunk and so on.

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): no What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): fluentd timezone timeformat Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): What happened: Log lines from docker have the wrong timestamp. Anything else do we need to know: We are building a custom Docker Image for fluentd/td-agent which is based on your Dockerfile but with some slight changes. One of which is that we set the timezone to something else than UTC. In this case fluentd will produce wrong timestamps for log lines since the string only includes a simple Z in the end. Changing the time_format to fixed the problem for us. Of course this is not really a bug in kubernetes but changing the default to the above will probably help others in the future.
Thanks for reporting! It seems to be a bug
Change:
// Find the number of references to the device. refCount := 0 for i := range mps { <del> if strings.HasPrefix(mps[i].Device, deviceNamePrefix) { </del> <ins> if strings.HasPrefix(mps[i].Path, deviceNamePrefix) { </ins> refCount++ } }

Discussion:
During iscsi volume cleanup, kubelet reads from and retrieves a list of device paths where iscsi volume mounts on. The device path was expected to be in the form of . But currently the device path in is in the form of , thus iscsi panicked . I suspect this panic started to happen after switched to use from . seems to always resolve device path (see output below), and thus the expected iscsi configuration in the device path no longer exists.
Change:
return nil, err } <del> ipList := make([]string, len(ipInfoList.Items)) for i, ip := range ipInfoList.Items { ipList[i] = ip.Subsets[0].Addresses[0].IP </del> <ins> ipList := make([]string, 0, len(ipInfoList.Items)) for _, ip := range ipInfoList.Items { if len(ip.Subsets) > 0 && len(ip.Subsets[0].Addresses) > 0 && len(ip.Subsets[0].Addresses[0].IP) > 0 { ipList = append(ipList, ip.Subsets[0].Addresses[0].IP) } </ins> } klog.V(6).Infof("Current master IPs listed in storage are %v", ipList)

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: In kubernetes 1.15, Panic happends in kube-apiserver. Subsets[0] is nil when endpoints has no subsets The Panic happens in here: And everything returns to normal when we delete the endpoints in etcd What you expected to happen: Maybe kube-apiserver should print error,not panic How to reproduce it (as minimally and precisely as possible): The host's iowait of ETCD is high Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:NA OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig release
/remove-sig release /sig api-machinery
/assign
Change:
// Confirm desired public ip resource exists var pip *network.PublicIPAddress domainNameLabel := getPublicIPDomainNameLabel(service) <del> if pip, err = az.ensurePublicIPExists(service, desiredPipName, domainNameLabel); err != nil { </del> <ins> if pip, err = az.ensurePublicIPExists(service, desiredPipName, domainNameLabel, clusterName); err != nil { </ins> return nil, err } return pip, 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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
return err }) }) <ins> ginkgo.It("should get and update a ReplicationController scale", func() { rcClient := f.ClientSet.CoreV1().ReplicationControllers(ns) rcName := "e2e-rc-" + utilrand.String(5) initialRCReplicaCount := int32(1) expectedRCReplicaCount := int32(2) ginkgo.By(fmt.Sprintf("Creating ReplicationController %q", rcName)) rc := newRC(rcName, initialRCReplicaCount, map[string]string{"name": rcName}, WebserverImageName, WebserverImage, nil) _, err := rcClient.Create(context.TODO(), rc, metav1.CreateOptions{}) framework.ExpectNoError(err, "Failed to create ReplicationController: %v", err) err = wait.PollImmediate(1*time.Second, 1*time.Minute, checkReplicationControllerStatusReplicaCount(f, rcName, initialRCReplicaCount)) framework.ExpectNoError(err, "failed to confirm the quantity of ReplicationController replicas") ginkgo.By(fmt.Sprintf("Getting scale subresource for ReplicationController %q", rcName)) scale, err := rcClient.GetScale(context.TODO(), rcName, metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get scale subresource: %v", err) framework.ExpectEqual(scale.Status.Replicas, initialRCReplicaCount, "Failed to get the current replica count") ginkgo.By("Updating a scale subresource") scale.ResourceVersion = "" // indicate the scale update should be unconditional scale.Spec.Replicas = expectedRCReplicaCount _, err = rcClient.UpdateScale(context.TODO(), rcName, scale, metav1.UpdateOptions{}) framework.ExpectNoError(err, "Failed to update scale subresource: %v", err) ginkgo.By(fmt.Sprintf("Verifying replicas where modified for replication controller %q", rcName)) err = wait.PollImmediate(1*time.Second, 1*time.Minute, checkReplicationControllerStatusReplicaCount(f, rcName, expectedRCReplicaCount)) framework.ExpectNoError(err, "failed to confirm the quantity of ReplicationController replicas") }) </ins> }) func newRC(rsName string, replicas int32, rcPodLabels map[string]string, imageName string, image string, args []string) *v1.ReplicationController {

Discussion:
[X] Test approval issue: [X] Test PR: 29 Sept 2022 [X] Two weeks soak end date: 14 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still two remaining ReplicationControllerScale endpoints which are untested for conformance. readCoreV1NamespacedReplicationControllerScalereplaceCoreV1NamespacedReplicationControllerScale Using a number of existing e2e test practices a new has been created for two ReplicationControllerScale endpoints. The e2e logs for this test are listed below. This query shows which scale endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 2 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
Change:
artifacts="${ARTIFACTS:-"/tmp/_artifacts/$(date +%y%m%dT%H%M%S)"}" remote=${REMOTE:-"false"} remote_mode=${REMOTE_MODE:-"gce"} <del> container_runtime_endpoint=${CONTAINER_RUNTIME_ENDPOINT:-""} </del> <ins> container_runtime_endpoint=${CONTAINER_RUNTIME_ENDPOINT:-"unix:///run/containerd/containerd.sock"} </ins> image_service_endpoint=${IMAGE_SERVICE_ENDPOINT:-""} run_until_failure=${RUN_UNTIL_FAILURE:-"false"} test_args=${TEST_ARGS:-""}

Discussion:
$ make test-e2e-node fails with an error because of the docker deprecation. I think we have to fix the default options for helper scripts. $ make test-e2e-node succeeds in common cases by default. $ make test-e2e-node No response_ <details</details<details</details<details</details<details</details<details</details<details</details/assign
/sig node
/cc
/assign
/triage accepted /assign /priority important-soon
Change:
const ( // AffinityTypeNone - no session affinity. <del> GCEAffinityTypeNone GCEAffinityType = "None" </del> <ins> GCEAffinityTypeNone GCEAffinityType = "NONE" </ins> // AffinityTypeClientIP is the Client IP based. GCEAffinityTypeClientIP GCEAffinityType = "CLIENT_IP" // AffinityTypeClientIP is the Client IP based.

Discussion:
Hi, I have a problem with my GCE cluster about LoadBalancer type Services It's creating a lot of unused static external IP on the google network of my project the cluster is running kubernetes v1.1.2. Tried restarting nodes, tried destroy/recreate of the entire cluster.
Seeing exactly the same issue at GKE since a few hours. First on a v1.0.7 cluster which I later upgraded to v1.1.2 to fix the problem but the issue is still there. Double checked my yaml config files but no changes from our side. Existing loadbalancers do work as before.
I dealt with this last night and a workaround was to add to the spec
Thx :+1:
We'll get this cherry picked into the two release branches once it's been verified at HEAD.
Change:
kubeReserved, err := parseResourceList(s.KubeReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--kube-reserved value failed to parse: %w", err) </ins> } systemReserved, err := parseResourceList(s.SystemReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--system-reserved value failed to parse: %w", err) </ins> } var hardEvictionThresholds []evictionapi.Threshold // If the user requested to ignore eviction thresholds, then do not set valid values for hardEvictionThresholds here.

Discussion:
During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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