jiebi/CodeConvo huggingface dataset:
Change:
informerFactory.Start(wait.NeverStop) testPod := validPod("testPod", 1, api.ResourceRequirements{}) <del> err = handler.Admit(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "", admission.Update, false, nil)) </del> <ins> err = handler.Admit(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "", admission.Create, false, nil)) </ins> if err != nil { t.Fatal(err) } <del> err = handler.Validate(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "", admission.Update, false, nil)) </del> <ins> err = handler.Validate(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "", admission.Create, false, nil)) </ins> if err == nil { <del> t.Errorf("Expected an error since the pod did not specify resource limits in its update call") </del> <ins> t.Errorf("Expected an error since the pod did not specify resource limits in its create call") } err = handler.Validate(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "", admission.Update, false, nil)) if err != nil { t.Errorf("Expected not to call limitranger actions on pod updates") </ins> } err = handler.Validate(admission.NewAttributesRecord(&testPod, nil, api.Kind("Pod").WithVersion("version"), limitRange.Namespace, "testPod", api.Resource("pods").WithVersion("version"), "status", admission.Update, false, nil))

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pod stuck in terminating state. What you expected to happen: Pod successfully cleaned up. How to reproduce it (as minimally and precisely as possible): up a LimitRange. (Say "limits: defaultRequest: cpu: 100m type: Container") a mutating webhook on pod which creates an additional container on the pod (Eg. ) without the limit range. a Pod with foreground deletion finalizer. that you have a Pod with 2 containers. The 1 you created which now has a limit and the istio container which does not. to delete the Pod. garbage collector tries to update the pod to remove the finalizer, however this triggers the limit range admission control to add the limit to the istio container. This then causes the API server to get the error "invalid: spec: Forbidden: pod updates may not change fields other than , , or " the pod is now stuck in terminating. Anything else we need to know?: Environment: Kubernetes version (use ): 1.9.6 /sig api-machinery
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
/remove-lifecycle stale PR open
Change:
t.Error("Expected error, but got success") } <del> if err != nil && !strings.Contains(err.Error(), tt.expectedErr) { t.Fatalf("enforceRequirements returned unexpected error, expected: %s, got %v", tt.expectedErr, err) </del> <ins> expErr := tt.expectedErr // pre-flight check expects the user to be root, so the root and non-root should hit different errors if os.Getuid() != 0 && len(tt.expectedErrNonRoot) != 0 { expErr = tt.expectedErrNonRoot } if err != nil && !strings.Contains(err.Error(), expErr) { t.Fatalf("enforceRequirements returned unexpected error, expected: %s, got %v", expErr, err) </ins> } })

Discussion:
unit tests should run without root. This test should be refactored or otherwise removed from . should pass as an ordinary user. run tests as non-root
/sig cluster-lifecycle /area kubeadm
thanks for logging the issue. this was changed in so this root preflight test must be excluded.
/triage accepted link
Change:
cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" ) <ins> /* WARNING: this logic is duplicated, with minor changes, in cmd/hyperkube/kubectl.go Any salient changes here will need to be manually reflected in that file. */ </ins> func Run() error { cmd := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, os.Stdout, os.Stderr) return cmd.Execute()

Discussion:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .
Change:
} else { allNames.Insert(ctr.Name) } <ins> // TODO: do not validate leading and trailing whitespace to preserve backward compatibility. // for example: https://github.com/openshift/origin/issues/14659 image = " " is special token in pod template // others may have done similar </ins> if len(ctr.Image) == 0 { allErrs = append(allErrs, field.Required(idxPath.Child("image"), "")) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version (use ): kubernetes 1.5+ Environment: n/a What happened: examining events that happened in my cluster, i see an event like the following: this surprised me, as it implies a container had an imageName=" " What you expected to happen: i expected a validation failure error if a [i].imageName had leading or trailing whitespace. How to reproduce it (as minimally and precisely as possible): kubectl create -f my-pod kubectl edit pod/my-pod -o json change image to " " save Anything else we need to know: nope
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
discovered when looking at odd event messages in production cluster.
Change:
"github.com/coreos/etcd/store" "github.com/coreos/etcd/wal" "github.com/coreos/etcd/wal/walpb" <ins> "github.com/coreos/go-semver/semver" </ins> "github.com/golang/glog" )

Discussion:
I tried to do a rollback on my own test cluster and got a panic. I will attach the data-dir tarball. The script that performs the migration goes from 2.2.1-2.3.7-3.0.14-2.3.7, and it is this last step that barfs. Script is forthcoming in a PR, but there's a snapshot at
This seems that it's not even about the real data, but about some metadata of the cluster. - any thoughts on it?
Is the data you uploaded the original data before 2.2.1-2.3.7?
yes
The rollback tool couldn't accept any v2 data existed. One way to make it work is to remove snap files:
To clarify, the panic is caused by existing v2 snap files. In the migrate step 2.3.7 -3.0.x, the script didn't remove v2 snap files.
- thanks a lot for looking into it. I will add a step to our migration script to remove the v2 data before rollback. Did it work after removing the data?
send out for review
To clarify - I verified that it fixed the problem reported (rollback works on the data provided in the issue).
The fix in the shell script is good, but the error message in the rollback tool could definitely be improved upon.
says that removing the snap file was not the right way to go.
i marked as milestone 1.5 and marking this as a non-release-blocker. hope this is correct.
Hmm... I tried re-running this on my test data, and now 2.3.7 always panics after the last step, whether I begin with backup data or not. Here is the data before running rollback: after running rollback:
I do not understand this. Does the migration tool still panic? Or the etcd 2.3.7 panics? etcd 2.3.7 should panic if you build the migration tool with 3.0 wal pkg. I believe I sent you the correct migration binary over slack.
Can we close this issue if the rollback tool stop panics? If the migrated data panics etcd 2.3, it is expected. And there is some other issues tracking it. I think we went though them a few weeks ago before thinks giving.

your slack message was lost while I was out of office, but the attached file is still there. Trying it now.
it works with the binary you shared. We still need a way to build that binary, but I will open a separate issue about that.
Change:
return newFakeAPIResourceConfigSource() }, expectedAPIConfig: func() *serverstore.ResourceConfig { <del> config := newFakeAPIResourceConfigSource() config.DisableVersions(extensionsapiv1beta1.SchemeGroupVersion) return config </del> <ins> return newFakeAPIResourceConfigSource() </ins> }, <del> err: true, </del> <ins> err: false, // no error for backwards compatibility </ins> }, } for index, test := range testCases {

Discussion:
https://k8s- sample failure: (also affecting other CI jobs) cc /sig gcp
/assign We're interested in disabling the job as blocking entirely. We're of the opinion this shouldn't have bee allowed to block the community in the first place. I swear there's a historical issue around tightening the regex somewhere.
... wrong button sorry about that
possibly caused by erroring on invalid values that were previously silently skipped opened to downgrade that error to a warning for a release
Well, I mentioned the idea of making the job optional in
PR out to drop the runifchanged regex from pull-kubernetes-e2e-gke
Confirmed turns the test green
Can call this closed when merges
/pony hooray
Couldn't find a pony matching that query. <detailsIn response to : /pony hooray 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:
"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically("==", value), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }

Discussion:
There's been a quite a few failures across jobs that query node metrics. The test is Last passing - First failing - appears to point to which is bump in prometheus client library. Possibly related? /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
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
Verified with presubmit that reverting the prometheus client library results in the test passing. Opened PR for revert in
/cc
/assign
thanks for filing this issue! I think seems like a promising fix (thanks ) and there's a fair chance we won't need the revert
ack, thanks for the fix, it seems we can go with that then and hold the revert.
Change:
func testCheckStop(t *testing.T, i int, w watch.Interface) { select { <del> case _, ok := <-w.ResultChan(): </del> <ins> case e, ok := <-w.ResultChan(): </ins> if ok { <del> t.Errorf("#%d: ResultChan should have been closed", i) </del> <ins> var obj string switch e.Object.(type) { case *api.Pod: obj = e.Object.(*api.Pod).Name case *unversioned.Status: obj = e.Object.(*unversioned.Status).Message } t.Errorf("#%d: ResultChan should have been closed. Event: %s. Object: %s", i, e.Type, obj) </ins> } case <-time.After(wait.ForeverTestTimeout): t.Errorf("#%d: time out after waiting 1s on ResultChan", i)

Discussion:
It failed in cc
I have some hypothesis. But I need to verify it. I will submit something to print more info in the test.
and others referencing this Please share links to unit test logs
We are able to reproduce this locally and confirm the failure: Submitted to fix it.
For a concrete reason why the test failed: That specific sequence is kinda non-blocking because the object is filtered. It calls Stop() really fast and cancel context. sync() returns context.Canceled
Change:
requestSizeInMegabytes:   requestSizeInMegabytes, } go rc.makeConsumeCPURequests() <del> rc.ConsumeCPU(initCPU) </del> <ins> rc.ConsumeCPU(initCPUTotal) </ins> go rc.makeConsumeMemRequests() <del> rc.ConsumeMem(initMemory) </del> <ins> rc.ConsumeMem(initMemoryTotal) </ins> return rc }

Discussion:
Is this fixed via the merged PR?
There are two issues: one is fixed by and another is fixed by , however it requires also new release of Heapster which hasn't been done yet so that I haven't closed this issue.
related PRs ,
It looks like you're on top of this, but it's been failing pretty frequently this morning as well, all on "Horizontal pod autoscaling [Skipped][Autoscaling Suite] should scale from 5 pods to 3 pods and from 3 to 1 (scale resource: Memory)"
The issue is about cluster size autoscaling tests, which haven't failed since was merged. I'll close this issue tomorrow once there will be no more failures. Also there is another issue with Horizontal Pod Autoscaling test - tracking issue
The test is stable now so closing the issue.
This problem is occurring again:
blocking merges; raising to P0
looks like was merged to hopefully address this. Lowering to p1.
Yep, disabled the test, tracking issue and there is fix in flight
Closing as is resolved.
Change:
$ kubectl get pods ``` <del> If you ssh to that machine, you can run `docker ps` to see the actual pod and `mount` to see if the Glusterfs volume is mounted. </del>  No newline at end of file <ins> If you ssh to that machine, you can run `docker ps` to see the actual pod and `mount` to see if the Glusterfs volume is mounted. </ins>

Discussion:
a set of endpoints to your GlusterFS cluster. Example a pod that uses the GlusterFS Volume Plugin in ReadWrite Mode (readonly=false) to mount a particular GlusterFS volume. Example the pod is running the contents of that GlusterFS Volume and see that your files exist. the pod - "kubectl delete pod glusterfs" the contents of your GlusterFS Volume and see that your files no longer exist. Environment: GlusterFS - verified with GlusterFS running on either Fedora 21 or RHEL 6.5. Kubernetes - running on Fedora 21 Note: This issue does not occur if the GlusterFS Volume Plugin is in ReadOnly Mode (readonly=true)
heh, this is why I wanted to refactor the mount/unmount/cleanup code - get it right once :)
cc
I went back to commit (the original merge for glusterfs volume) and couldn't replicate the bug. after updating to HEAD i could replicate. so something changed between first merge and HEAD causing issue.
It's caused by commit : This is called before unmounting of volumes, which are mounted somewhere into . why RemoveAll()? It was not there before your commit.
Fixed in PR
Sorry for injecting the bug. I was thinking of moving volume & pod dir cleanup into the function, but it didn't pan out, and the code was left unintentionally. Thanks for fixing it! The logic still seems strange in some cases. looks at the containers we failed to kill, and skip cleaning up volumes associated with them. But doesn't look at the those containers and would just go ahead and remove the directories for all the pods that we supposedly killed. I will file and issue later.
Is this fixed now? If so, please close. , Yu-Ju Hong wrote:
Change:
clusterNameKey = "kubernetes-cluster-name" ) <del> var ( // supportedServiceTags holds a list of supported service tags on Azure. // Refer https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags for more information. supportedServiceTags = sets.NewString("VirtualNetwork", "VIRTUAL_NETWORK", "AzureLoadBalancer", "AZURE_LOADBALANCER", "Internet", "INTERNET", "AzureTrafficManager", "Storage", "Sql") ) </del> // GetLoadBalancer returns whether the specified load balancer exists, and // if so, what its status is. func (az *Cloud) GetLoadBalancer(ctx context.Context, clusterName string, service *v1.Service) (status *v1.LoadBalancerStatus, exists bool, err error) {

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: Azure cloud provider has a limited support for service tags by annotations: But according to , there are actually much more service tags than this list. Hence, errors would happen if the service tag is not included in the above list. What you expected to happen: Azure cloud provider should support all service tags from Azure. 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: /kind bug /sig azure /priority important-soon
/assign
Change:
gomega.Expect(p.Status.HostIPs).Should(gomega.BeNil()) ginkgo.By("deleting the pod") <del> err := podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(30)) </del> <ins> err := podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(1)) </ins> framework.ExpectNoError(err, "failed to delete pod") })

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network node
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
/assign
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
) const ( <del> criticalPodName            = "critical-pod" guaranteedPodName          = "guaranteed" burstablePodName           = "burstable" bestEffortPodName          = "best-effort" systemCriticalPriorityName = "critical-pod-test-high-priority" </del> <ins> criticalPodName   = "static-critical-pod" guaranteedPodName = "guaranteed" burstablePodName  = "burstable" bestEffortPodName = "best-effort" </ins> ) var _ = framework.KubeDescribe("CriticalPod [Serial] [Disruptive] [NodeFeature:CriticalPod]", func() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
return nil, fmt.Errorf("pod %q container %q changed request for resource %q from %d to %d", string(podUID), contName, resource, devices.Len(), required) } } <del> klog.V(3).InfoS("Need devices to allocate for pod", "deviceNumber", needed, "resourceName", resource, "podUID", string(podUID), "containerName", contName) healthyDevices, hasRegistered := m.healthyDevices[resource] // Check if resource registered with devicemanager if !hasRegistered { return nil, fmt.Errorf("can't allocate unregistered device %s", resource) } // Check if registered resource has healthy devices if healthyDevices.Len() == 0 { return nil, fmt.Errorf("can't allocate unhealthy devices %s", resource) } // Check if all the previously allocated devices are healthy if !healthyDevices.IsSuperset(devices) { return nil, fmt.Errorf("previously allocated devices are no longer healthy; can't allocate unhealthy devices %s", resource) } </del> if needed == 0 { // No change, no work. return nil, nil } <ins> klog.V(3).InfoS("Need devices to allocate for pod", "deviceNumber", needed, "resourceName", resource, "podUID", string(podUID), "containerName", contName) // Check if resource registered with devicemanager if _, ok := m.healthyDevices[resource]; !ok { return nil, fmt.Errorf("can't allocate unregistered device %s", resource) } </ins> // Declare the list of allocated devices. // This will be populated and returned below.

Discussion:
Failing: ` Failing since . Last passing: First failing:
The diff () shows that went in which looks related
/sig node
/kind regression /kind bug /triage accepted
Change:
registry              = initReg() dockerLibraryRegistry = registry.DockerLibraryRegistry e2eRegistry           = registry.E2eRegistry <del> etcdRegistry          = registry.EtcdRegistry </del> gcRegistry            = registry.GcRegistry // PrivateRegistry is an image repository that requires authentication PrivateRegistry = registry.PrivateRegistry

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: I see only amd64 architecture etcd is used for the which will create issues for the other architectures like ppc64le, arm etc. We need to replace this etcd image with the k8s maintained fat manifest image present in
/sig testing
Change:
syncPeriod    time.Duration minSyncPeriod time.Duration // Values are CIDR's to exclude when cleaning up IPVS rules. <del> excludeCIDRs []string </del> <ins> excludeCIDRs []*net.IPNet </ins> // Set to true to set sysctls arp_ignore and arp_announce strictARP      bool iptables       utiliptables.Interface

Discussion:
What would you like to be : Change excludeCIDRs from []string to []*IPNet in Proxier and perform the parsing at construction of Proxier. Why is this needed: This was proposed by over comments in Pr This improves the performance of isIPInExcludeCIDRs since the cost of parsing becomes one time.
/sig network /kind cleanup
/remove-kind feature
/triage unresolved I am a bot run by ‍
ping
Change:
Value: "tcp://machine:8080", }, { <del> Name:  "TEST_PORT_900_TCP", </del> <ins> Name:  "TEST_PORT_8080_TCP", </ins> Value: "tcp://machine:8080", }, { <del> Name:  "TEST_PORT_900_TCP_PROTO", </del> <ins> Name:  "TEST_PORT_8080_TCP_PROTO", </ins> Value: "tcp", }, { <del> Name:  "TEST_PORT_900_TCP_PORT", </del> <ins> Name:  "TEST_PORT_8080_TCP_PORT", </ins> Value: "8080", }, { <del> Name:  "TEST_PORT_900_TCP_ADDR", </del> <ins> Name:  "TEST_PORT_8080_TCP_ADDR", </ins> Value: "machine", }, {

Discussion:
We have seen that on VirtualBox in particular kubelet picks first interfaces, which is usually NATed and is of no use. In particular the issue comes up with service IP, which gets mapped to endpoint on the NATed interface.
If this is still a problem, can you explain more - I don't quite understand - and suggest heuristics for better solutions?
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale