jiebi/CodeConvo huggingface dataset:
Change:
# # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> curl -L http://bootstrap.saltstack.org | sh -s -- -X </del> <ins> curl -L http://bootstrap.saltstack.com | sh -s -- -X </ins>

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: After deleting a pod and scaling up the statefulset with different valid envs in the same container simultaneously, then the output events of executing the command is below: What you expected to happen: update successfully. How to reproduce it (as minimally and precisely as possible): a statefulset. apply this statefulset's yaml: After a while, execute , and the pod is running a new stateful's yaml, which a new env key and more replicas. the pod and apply a new stateful's yaml the statefulset Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
/sig apps
Meet same problem while using kube-addon-manager. vs and patchStrategy
+1
In some cases, add in the env which using can solve the problem.
/assign
I think the root cause of this is the strategic patch. As mentioned, we have to use the to fix the problem which tells the strategic patch to remove the field so the spec could pass the validation process of statefulsets. It would lead to API broken if we change the behaviour of strategic merge patch, I'll dig around in the apps validation process and try to find out the solution to this.
Thank you for your reply. According to your advice, I tried to add in my second statefulset's yaml, but I still could not update statefulset correctly. How to fix my yamls to get around the problem?

/unassign Sorry, I do not have enough time for this, anyone interested could take it from here.
I don't think the problem comes from your YAML, the problem comes from the controller that doesn't update the fields properly.
/assign
Change:
} }, "topologyKey": { <del> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed.", </del> <ins> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed.", </ins> "type": "string" } }

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
virtualMachineConfigSpec.DeviceChange = append(virtualMachineConfigSpec.DeviceChange, deviceConfigSpec) fileAlreadyExist := false task, err := dummyVM.Reconfigure(ctx, virtualMachineConfigSpec) <ins> if err != nil { glog.Errorf("Failed to reconfig. err: %v", err) return "", err } </ins> err = task.Wait(ctx) if err != nil { fileAlreadyExist = isAlreadyExists(vmdisk.diskPath, err)

Discussion:
Hi, I am currently working on k8s cloud provider and I ran in pkg/cloudprovider package. Turned out that some providers code have unused variables and logic problems. Here is the report: session.New is deprecated some bugs and unused values oauth2.NoContext is deprecated, overwritten ctx and miss error checks missing error check unused values missing error check, loop logic issues Hope this report can help to cloud provider working groups. :)
/kind bug /sig cloud-provider /sig vmware
PR open for vsphere cloud provider
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
Change:
) func (c *FakeEvents) CreateWithEventNamespace(event *v1.Event) (*v1.Event, error) { <del> action := core.NewRootCreateAction(eventsResource, event) </del> <ins> var action core.CreateActionImpl </ins> if c.ns != "" { action = core.NewCreateAction(eventsResource, c.ns, event) <ins> } else { action = core.NewCreateAction(eventsResource, event.GetNamespace(), event) </ins> } obj, err := c.Fake.Invokes(action, event) if obj == nil {

Discussion:
Opening this issue based on what I ran into on with namespace as follows While unit testing the controller, we create a fake client and setup the controller to run using the client. This ends up creating a having the namespace set to When the call eventually reaches The action gets associated with a namespace only if the object has a namespace associated with it. Which in this will be Which will result in the error in to manage the event like does. In case if the namespace is set to Above is a test case that can easily simulate the issue in question. Referring back to the test under PR NA <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted 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
/assign
Change:
<ins> # Copyright 2016 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. FROM gliderlabs/alpine MAINTAINER Mehdy Bohlool <mehdy@google.com> RUN apk-install bash ADD etcd-empty-dir-cleanup.sh etcd-empty-dir-cleanup.sh ADD etcdctl etcdctl ENV ETCDCTL /etcdctl ENV SLEEP_SECOND 3600 RUN chmod +x etcd-empty-dir-cleanup.sh CMD bash /etcd-empty-dir-cleanup.sh </ins>

Discussion:
I came upon a cluster that had had the namespace code thoroughly exercised. No namespaces currently existed, but many had been created and deleted in the past. Its etcd had lots of empty directories under each resource that had held items when those namespaces were alive (secrets, serviceaccounts, pods...). Do we need to be doing something to clean these empty directories up? It seems like this etcd was consuming a lot of memory.
or might know the answer to this question.
Right. We should delete them. It might get tricky for concurrent cases like A checks if dir is empty, B creates, then A deletes it. What does it look like currently in creating and deleting namespace?
How much memory does a directory entry take? Does it really sound possible to run out of memory while snapshotting on account of too many empty directories?
-- have you guys encountered this? I think you run with more namespaces than we do. But maybe yours are mostly populated?
Yes, we've seen it. c.f.
Approximate memory use we saw from empty dirs:
cc
The patch we debated carrying is here: Our hope was to just wait to etcd v3 where this would not be a problem.
can you link to your clean-up script here?
I needed another PR to run the pod automatically on master.
Change:
key := buildVmssCacheKey(nodeResourceGroup, ss.makeVmssVMName(ssName, instanceID)) defer ss.vmssVMCache.Delete(key) <del> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s)", nodeResourceGroup, nodeName, diskName) _, err = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM) </del> <ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s, %s)", nodeResourceGroup, nodeName, diskName, diskURI) resp, err := ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM) if ss.CloudProviderBackoff && shouldRetryHTTPRequest(resp, err) { klog.V(2).Infof("azureDisk - update(%s) backing off: vm(%s) detach disk(%s, %s), err: %v", nodeResourceGroup, nodeName, diskName, diskURI, err) retryErr := ss.UpdateVmssVMWithRetry(nodeResourceGroup, ssName, instanceID, newVM) if retryErr != nil { err = retryErr klog.V(2).Infof("azureDisk - update(%s) abort backoff: vm(%s) detach disk(%s, %s), err: %v", nodeResourceGroup, nodeName, diskName, diskURI, err) } } </ins> if err != nil { <del> klog.Errorf("azureDisk - detach disk(%s) from %s failed, err: %v", diskName, nodeName, err) </del> <ins> klog.Errorf("azureDisk - detach disk(%s, %s) from %s failed, err: %v", diskName, diskURI, nodeName, err) </ins> } else { <del> klog.V(2).Infof("azureDisk - detach disk(%s) succeeded", diskName) </del> <ins> klog.V(2).Infof("azureDisk - detach disk(%s, %s) succeeded", diskName, diskURI) </ins> } return err

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: Current azure cloud provider would fail to detach azure disk when there is server side error, need to add retry mechanism for detach disk operation, while for attach disk operation, it's not necessary since k8s pv-controller will try if first try failed. 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.10 ~ master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
{ObjectMeta: metav1.ObjectMeta{Name: "nodeB", Labels: label2}}, {ObjectMeta: metav1.ObjectMeta{Name: "nodeC", Labels: label3}}, }, <ins> expectedAntiAffinity: topologyToMatchedTermCount{}, expectedAffinity: topologyToMatchedTermCount{ {key: "region", value: "r1"}: 2, {key: "zone", value: "z11"}:  2, }, </ins> }, }

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: Maybe it should be 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 ): 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 Scheduling
I feel it is a valid error. But need confirmation from sig-scheduling maintainers. ... is it okay if I work on this?
ok
Yeah, this is a bug in preemption
/assign
Change:
}, time.Minute, time.Second*4).Should(BeNil()) }) <del> It("should be possible to delete [NodeConformance]", func() { </del> <ins> /* Release : v1.13 Testname: Kubelet, failed pod, delete Description: Create a Pod with terminated state. This terminated pod MUST be able to be deleted. */ framework.ConformanceIt("should be possible to delete [NodeConformance]", func() { </ins> err := podClient.Delete(podName, &metav1.DeleteOptions{}) Expect(err).To(BeNil(), fmt.Sprintf("Error deleting Pod %v", err)) })

Discussion:
What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. To my eyes they may meet the criteria for conformance. There's definitely nothing about them that is node specific. They should be running as part of our regular CI, and they should probably be running as presubmits. Porting them to test/e2e/common would cause this to happen. /kind cleanup /sig node /area test /assign
GitHub didn't allow me to assign the following users: mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. /sig node /area test /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
Change:
ginkgo.By("Sending the expected data to the local port") fmt.Fprint(conn, "abc") <del> ginkgo.By("Closing the write half of the client's connection") if err = conn.CloseWrite(); err != nil { framework.Failf("Couldn't close the write half of the client's connection: %v", err) } </del> ginkgo.By("Reading data from the local port") fromServer, err := ioutil.ReadAll(conn) if err != nil {

Discussion:
Which jobs are flaking: pull-kubernetes-e2e-gce Which test(s) are flaking: Testgrid link: /sig cli
This test seems to stop flake. Can you check if we can close this issue?
still looks flaky to me
Can you take a look?
/milestone v1.19
have you had a chance to look into this?
Possibly related to
Let's see if removing makes it less flaky
Change:
func (*RemoveImageResponse) Descriptor() ([]byte, []int) { return fileDescriptorApi, []int{76} } type NetworkConfig struct { <del> // CIDR to use for pod IP addresses. </del> <ins> // CIDR to use for pod IP addresses. If the CIDR is empty, runtimes // should omit it. </ins> PodCidr string `protobuf:"bytes,1,opt,name=pod_cidr,json=podCidr,proto3" json:"pod_cidr,omitempty"` }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In my test setup I allocate POD CIDRs manually, bridge is configured before starts. Important settings: on example node: on master: Then I see confusing entries in logs (): Fortunately everything keeps working, thanks to this condition: , i.e. it is not propagated to CNI plugin. It appears that this very line tries to set the CIDR to whatever the master returns during node status update: What you expected to happen: / use the pod CIDR given at command line and never mess with it Actually I'm a bit confused if manual per-node pod CIDR assignment is supported at all, and if I'm doing it correctly. I'm aware it's unusual thing to do in production environment, yet for testing it seems perfectly legitimate. Environment: Kubernetes version (use ): v1.10.0 Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Ubuntu 17.10 Kernel (e.g. ): Install tools:
/sig network
Kubelet need to make a check of CIDR before
/assign
Change:
_, err = m.cs.StorageV1beta1().VolumeAttachments().Get(attachmentName, metav1.GetOptions{}) if err != nil { if errors.IsNotFound(err) { <del> if test.driverAttachable { </del> <ins> if !test.disableAttach { </ins> framework.ExpectNoError(err, "Expected VolumeAttachment but none was found") } } else { framework.ExpectNoError(err, "Failed to find VolumeAttachment") } } <del> if !test.driverAttachable { </del> <ins> if test.disableAttach { </ins> Expect(err).To(HaveOccurred(), "Unexpected VolumeAttachment found") } })

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear
Change:
Httpd // HttpdNew image HttpdNew <del> // Invalid image Invalid </del> // InvalidRegistryImage image InvalidRegistryImage // IpcUtils image

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:
Change:
// These are valid values for resource quota spec const ( <del> // Match all pod objects where spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds >=0 </ins> ResourceQuotaScopeTerminating ResourceQuotaScope = "Terminating" <del> // Match all pod objects where !spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds is nil </ins> ResourceQuotaScopeNotTerminating ResourceQuotaScope = "NotTerminating" // Match all pod objects that have best effort quality of service ResourceQuotaScopeBestEffort ResourceQuotaScope = "BestEffort"

Discussion:
The following comments are incomplete. For example, comments for "ResourceQuotaScopeTerminating" should be: Ref: /good-first-issue
/sig scheduling
/assign
Per ResourceQuota is within scope of api-machinery. /sig api-machinery /remove-sig scheduling
/assign
/unassign rakeshreddybandi
/remove-good-first-issue
Hi!! I'd like to help #investigate this problem I'm a beginner, so I'll make my best. Can you please help me point me in the right direction? What's the output today vs. how does the output should look like?
Oh I get it, the comments on top of the lines are not completely accurate on what the message displays, right? I think I got it
Yeah - But I've already opened a PR for this! - See the linked PR So this is already done, just waiting on final merge.
Great Dean, thanks for that!
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Change:
err := wait.Poll(framework.Poll, timeout, func() (bool, error) { endpoints, err := c.Endpoints(ns).Get(name) if err != nil { <del> if apierrs.IsNotFound(err) { </del> <ins> // log the real error framework.Logf("Get endpoints failed (interval %v): %v", framework.Poll, err) // if the error is API not found or could not find default credentials or TLS handshake timeout, try again if apierrs.IsNotFound(err) || apierrs.IsUnauthorized(err) || apierrs.IsServerTimeout(err) { </ins> err = nil } <del> framework.Logf("Get endpoints failed (interval %v): %v", framework.Poll, err) </del> return false, err }

Discussion:
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl expose should create services for rc [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention...