jiebi/CodeConvo huggingface dataset:
Change:
result := c.client.clientBase.Get(). AbsPath(path). <del> Namespace(c.namespace). </del> <ins> NamespaceIfScoped(c.namespace, c.namespace != ""). </ins> Resource(gvr.Resource). Name(name). SubResource("scale").

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The scale client () currently works fine with namespaced resources. However, it doesn't work for non-namespaced resources e.g. cluster-scoped CRDs. The current implementation should be extended in order to support non-namespaced resources. The current interface: /area custom-resources /sig autoscaling
I think scale subresource support for CRDs falls more into sig-apimachinery domain. After DirectXMan12 moved on from sig-autoscaling I don't think there is anyone in our sig-autoscaling with knowledge of scale subresource internals. /sig api-machinery
/assign
The bug report sounds legit. Does the generic scale client need to be changed (I think so), or does solve your issue?
No, the dashboard PR doesn't solve this. I discovered this issue while working on that PR so when gets merged, it will only work for namespaced CRDs. I think the generic scale client needs to be updated, maybe by adding another getter to the ScalesGetter interface: /kind bug
PR:
Change:
By(fmt.Sprintf("WARNING: possibly leaked static IP: %vn", ipErr)) } <del> // Fail if the controller didn't cleanup </del> <ins> // Logging that the GLBC failed to cleanup GCE resources on ingress deletion // See kubernetes/ingress#431 </ins> if pollErr != nil { <del> Failf("L7 controller failed to delete all cloud resources on time. %v", pollErr) </del> <ins> Logf("error: L7 controller failed to delete all cloud resources on time. %v", pollErr) </ins> } }

Discussion:
https://k8s- Failed: [] Loadbalancing: L7 [Feature:Ingress] [] GCE [Slow] [Feature: Ingress] shoud create ingress with given static-ip {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Loadbalancing: L7 [Feature:Ingress] [] GCE [Slow] [Feature: Ingress] shoud create ingress with given static-ip {Kubernetes e2e suite}
We are seeing these a lot in etcd rollback tests. Two different error messages.
Oh, here we go again. Another case for . Let me adjust the quota on that project.
I doubled the quota to 10. Watch upcoming runs .
points out that we may be leaking resources across runs, but I don't see a persistent leak. I doubled the quota on static IP addresses.
For unknown reasons, the GLBC is failing to delete the ingress resources. Unfortunately, the e2e fallback cleanup mechanism is also failing. It's trying to list resources via exec.Command( gcloud ... list --regexp=XYZ ) but always coming back with 0 resources. Putting the regular expression in quotes returns valid results. Expect a PR this afternoon.
PR is successfully deleting the remaining resources. The etcd upgrade test is now failing roughly half the time rather than continuously. After glancing over the recent failures, I've noticed a few consistent behaviors: objects are created and the l7 address is successfully hit. ingress objects are not cleaned up by the GLBC. (The test framework has to manually delete them) file does not contain log messages saying the ingress objects are being created. It also doesn't say that a delete ingress obj notification has been received. Log of glbc. glbc. I'm puzzled to why the ingress resources exist without the noting their creation. The other question is why the delete notification is not received/logged. Will investigate further...
for why the logs look incomplete, please see kubernetes/test-infra.
explains why this test does not clean up resources - causing the flake. [tl;dr] The GLBC only deletes L7 resources for ingress objects that it's cached locally. Caching happens soon after startup, but this races with the test's ingress deletion.
Thanks, Nick.

Oh, and now I see a comment that is relevant to this. That case should probably be .
this is to be closed by he is going to remove when this trips
-- can we bump this from the release-1.6? It does not seem to be blocking for the release.
done
Change:
&PartialObjectMetadataList{}, ) <ins> if err := scheme.AddConversionFuncs( Convert_Slice_string_To_v1alpha1_IncludeObjectPolicy, ); err != nil { panic(err) } </ins> // register manually. This usually goes through the SchemeBuilder, which we cannot use here. //scheme.AddGeneratedDeepCopyFuncs(GetGeneratedDeepCopyFuncs()...) }

Discussion:
Making an API request for table output and specifying the parameter causes a server error in parameter conversion, and an inaccurate error message in response: server log: E0804 09:41:14. ] apiserver received an error that is not an metav1.Status: converting (url.Values).[]string to (v1alpha1.TableOptions).v1alpha1.IncludeObjectPolicy: couldn't copy '[]string' into 'v1alpha1.IncludeObjectPolicy'; didn't understand types
Ugh, typed strings.
Change:
"io" "os" "path/filepath" <del> goruntime "runtime" </del> "testing" "time"

Discussion:
The test is failing on Windows [0]: The idea of the test is to check that kubelet still follows and reads the Container Logs after a Log Rotation occured. However, because the followed file is open, it cannot be renamed, and thus, the container logs cannot be rotated. This issue could be prevented if the file would be opened with the [0] [1] Kubelet should not block container log rotation. Run the test ` is failing on Windows. /sig windows /kind bug /kind failing-test latest, master. This unit test has been failing for a while. N/A Windows nodes </detailsN/A N/A N/A
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
/kind failing-test /sig windows
Change:
container: .container-${OS}-$(ARCH) .container-linux-$(ARCH): bin/$(BIN)-$(OS)-$(ARCH) docker buildx build --pull --output=type=${OUTPUT_TYPE} --platform ${OS}/$(ARCH)  <del> -t $(IMAGE_WITH_OS_ARCH):$(TAG) --build-arg BASE=${BASE} --build-arg ARCH=$(ARCH) . </del> <ins> -t $(IMAGE):$(TAG)-${OS}-$(ARCH) --build-arg BASE=${BASE} --build-arg ARCH=$(ARCH) . </ins> touch $@ .container-windows-$(ARCH): $(foreach binary, ${BIN}, bin/${binary}-${OS}-${ARCH}) docker buildx build --pull --output=type=${OUTPUT_TYPE} --platform ${OS}/$(ARCH)  <del> -t $(IMAGE_WITH_OS_ARCH)-${OSVERSION}:$(TAG) --build-arg BASE=${BASE}:${OSVERSION} --build-arg ARCH=$(ARCH) -f Dockerfile_windows . </del> <ins> -t $(IMAGE):$(TAG)-${OS}-$(ARCH)-${OSVERSION} --build-arg BASE=${BASE}:${OSVERSION} --build-arg ARCH=$(ARCH) -f Dockerfile_windows . </ins> touch $@ # Useful for testing, not automatically included in container image

Discussion:
We could either: where appropriate - least amount of code change but cumbersome OS version in the tag instead of the repository /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
/kind bug
Change:
Name(pod.Name). Namespace(pod.Namespace). SubResource("attach"). <del> Param("container", containerName) </del> <ins> Param("container", p.GetContainerName(pod)) </ins> return p.Attach.Attach(req, p.Config, stdin, p.Out, p.Err, tty) } <ins> // GetContainerName returns the name of the container to attach to, with a fallback. func (p *AttachOptions) GetContainerName(pod *api.Pod) string { if len(p.ContainerName) > 0 { return p.ContainerName } glog.V(4).Infof("defaulting container name to %s", pod.Spec.Containers[0].Name) return pod.Spec.Containers[0].Name } </ins>

Discussion:
runs foo and then waits for it to be ready or terminated. If the pod is terminated, it prints the log, and if it's not terminated, it attaches the output. However, it does not handle the case that the pod terminates between returning the ready status and attaching, as can be the case in the : Options to fix this: Fix kubectl: If attach fails, fall back to printing the logs If attach fails, check the status again and if it's terminated, print the logs Fix the flaky test: Prevent the container from exiting (e.g. `sh -c 'echo running in container && sleep 30') Prevent the container from entering ready state (e.g. )
Thanks for debugging. I think we should probably do both: If attach fails and the container is now terminated, fall back to printing logs Make the e2e more robust by not exiting for a while to ensure time to attach. I'm happy to review PRs
Change:
return false default: // Normal equality suffices <del> if v1.CanInterface() && v2.CanInterface() { return v1.Interface() == v2.Interface() </del> <ins> if !v1.CanInterface() || !v2.CanInterface() { panic(unexportedTypePanic{}) </ins> } <del> return v1.CanInterface() == v2.CanInterface() </del> <ins> return v1.Interface() == v2.Interface() </ins> } }

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
"//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//test/e2e/framework:go_default_library",

Discussion:
Which jobs are flaking: pull-kubernetes-e2e-kind Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig apps
Failure at
Hi I looked into the failures and think it was because the test required the job succeeds 3 times with pseudorandom 50% failure chance within 15 minutes, while there is an exponential back-off delay (10s, 20s, 40s …) capped at 6 minutes before recreating failed pods. As 7 consecutive failures (1/128 chance) could exceed the timeout, the test failed intermittently because of "timed out waiting for the condition". For example, in the failure of , the job pods succeeded and failed in the following orders: After the last failure at , the delay has increased to 640s so no pod was created any more before the test failed at . I think it can be fixed by using a deterministic approach to make the job pods succeed and fail alternately, and its executing time can be reduced to tens of seconds stably. Assigning myself. /assign
Change:
Expect(err).NotTo(HaveOccurred(), "while deleting pod") } <del> func testPodFailSubpath(f *framework.Framework, pod *v1.Pod) { testPodFailSubpathError(f, pod, "subPath") </del> <ins> func testPodFailSubpath(f *framework.Framework, pod *v1.Pod, allowContainerTerminationError bool) { testPodFailSubpathError(f, pod, "subPath", allowContainerTerminationError) </ins> } <del> func testPodFailSubpathError(f *framework.Framework, pod *v1.Pod, errorMsg string) { </del> <ins> func testPodFailSubpathError(f *framework.Framework, pod *v1.Pod, errorMsg string, allowContainerTerminationError bool) { </ins> By(fmt.Sprintf("Creating pod %s", pod.Name)) pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).ToNot(HaveOccurred(), "while creating pod")

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: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!
Change:
go run ./hack/e2e.go -v -build # Push to GCS <del> yes | ./build/push-ci-build.sh </del> <ins> ./build/push-ci-build.sh </ins> sha256sum _output/release-tars/kubernetes*.tar.gz

Discussion:
It looks like a test configuration failure:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/assign
last passing run: https://k8s- first failing run: https://k8s-
https://k8s- /close
Change:
} if sumPriorities < minSumPriorities { minSumPriorities = sumPriorities <del> minSumPriorityNodes = nil </del> <ins> lenNodes1 = 0 </ins> } if sumPriorities == minSumPriorities { <del> minSumPriorityNodes = append(minSumPriorityNodes, node) </del> <ins> minNodes1[lenNodes1] = node lenNodes1++ </ins> } } <del> if len(minSumPriorityNodes) == 1 { return minSumPriorityNodes[0] </del> <ins> if lenNodes1 == 1 { return minNodes1[0] </ins> } // There are a few nodes with minimum highest priority victim and sum of priorities. // Find one with the minimum number of pods. minNumPods := math.MaxInt32 <del> var minNumPodNodes []*v1.Node for _, node := range minSumPriorityNodes { </del> <ins> lenNodes2 = 0 for i := 0; i < lenNodes1; i++ { node := minNodes1[i] </ins> numPods := len(nodesToVictims[node].pods) if numPods < minNumPods { minNumPods = numPods <del> minNumPodNodes = nil </del> <ins> lenNodes2 = 0 </ins> } if numPods == minNumPods { <del> minNumPodNodes = append(minNumPodNodes, node) </del> <ins> minNodes2[lenNodes2] = node lenNodes2++ </ins> } } // At this point, even if there are more than one node with the same score, // return the first one. <del> if len(minNumPodNodes) > 0 { return minNumPodNodes[0] </del> <ins> if lenNodes2 > 0 { return minNodes2[0] </ins> } glog.Errorf("Error in logic of node scoring for preemption. We should never reach here!") return nil

Discussion:
<!-- 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 feature What happened: Fix the following : The basic logic in of using the is continuing reducing the nodes slices through , , and . It needs 4 slices to do this. This is my thought to reuse the slices: Use 2 nodes slices, such as , The reducing process becomes: -Clear -Clear - please give some suggestion, thanks :smile:
/sig scheduling
The challenge is that clearing a slice and reusing it still needs GC clean up, so it may not be effective. The size of slices shrink as we proceed through the function. So, having two slices and over-writing the elements in them can help reduce GC time, but this approach needs some additional checks to ensure we are not using stale elements.
To avoid clearing the slices, this is my thought: Declare to indicate the actual length of the 2 node slices, instead of . Appending a node to a node slice will add 1 to . Clearing a node slice will set to 0. WDYT
Yes, I can't think of any better solution either, but remember that you should append only to the slice in the first for loop of the function. The second slice should be initialized with the same number of elements as the slice used in the first for loop. Setting elements of the slices should be done by indexing them (not by append) in the second, third, and forth loop.
OK, I will submit a PR to implement it.
Change:
return []func(*v1.Node) error{ kl.setNodeAddress, withoutError(kl.setNodeStatusInfo), <ins> withoutError(kl.setNodeOODCondition), </ins> withoutError(kl.setNodeMemoryPressureCondition), withoutError(kl.setNodeDiskPressureCondition), withoutError(kl.setNodeReadyCondition),

Discussion:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close
Change:
"k8s.io/kubernetes/pkg/kubelet/apis/resourcemetrics/v1alpha1" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/prober" <ins> servermetrics "k8s.io/kubernetes/pkg/kubelet/server/metrics" </ins> "k8s.io/kubernetes/pkg/kubelet/server/portforward" remotecommandserver "k8s.io/kubernetes/pkg/kubelet/server/remotecommand" "k8s.io/kubernetes/pkg/kubelet/server/stats"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node
Change:
####################### # Make sure the UI can be proxied <del> start-proxy --api-prefix=/ </del> <ins> start-proxy </ins> check-curl-proxy-code /ui 301 check-curl-proxy-code /metrics 200 <ins> check-curl-proxy-code /api/ui 404 </ins> if [[ -n "${version}" ]]; then check-curl-proxy-code /api/${version}/namespaces 200 fi <ins> check-curl-proxy-code /static/ 200 </ins> stop-proxy <del> # Default proxy locks you into the /api path (legacy behavior) </del> <ins> # Make sure the in-development api is accessible by default </ins> start-proxy <del> check-curl-proxy-code /ui 404 check-curl-proxy-code /metrics 404 check-curl-proxy-code /api/ui 404 if [[ -n "${version}" ]]; then check-curl-proxy-code /api/${version}/namespaces 200 fi </del> <ins> check-curl-proxy-code /apis 200 check-curl-proxy-code /apis/extensions/ 200 </ins> stop-proxy # Custom paths let you see everything. <del> start-proxy --api-prefix=/custom </del> <ins> start-proxy /custom </ins> check-curl-proxy-code /custom/ui 301 check-curl-proxy-code /custom/metrics 200 if [[ -n "${version}" ]]; then

Discussion:
Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.
Change:
MASTER_EXTRA_METADATA=${KUBE_MASTER_EXTRA_METADATA:-${KUBE_EXTRA_METADATA:-}} # MASTER_EXTRA_METADATA is the extra instance metadata on node instance separated by commas. NODE_EXTRA_METADATA=${KUBE_NODE_EXTRA_METADATA:-${KUBE_EXTRA_METADATA:-}} <ins> # KUBELET_TEST_ARGS are extra arguments passed to kubelet. KUBELET_TEST_ARGS=${KUBE_KUBELET_EXTRA_ARGS:-} </ins> NETWORK=${KUBE_GCE_NETWORK:-default} # Enable network deletion by default (for kube-down), unless we're using 'default' network.

Discussion:
Sometimes users do need to specify some kubelet flags, e.g. configure kubelet container runtime cgroup based on their environment. Currently, user can only specify kubelet args with a hidden env for kube- We should formalize the name exposed to user.
/cc
Change:
} if len(o.Output) > 0 { <del> return o.PrintObject(o.Cmd, o.Local, o.Mapper, obj, o.Out) </del> <ins> if err := o.PrintObject(o.Cmd, o.Local, o.Mapper, obj, o.Out); err != nil { return err } continue </ins> } cmdutil.PrintSuccess(o.Mapper, o.ShortOutput, o.Out, info.Mapping.Resource, info.Name, false, "env updated")

Discussion:
<!-- 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?: What happened: my yaml: exec kubectl set resources command,just update first object: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind bug
/assign
Change:
testPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ <del> SelfLink:  "/api/v1/namespaces/baz/pods/foo", </del> Name:      "foo", Namespace: "baz", UID:       "bar",

Discussion:
Which jobs are flaking: periodic-kubernetes-bazel-test-master (xref ) Which test(s) are flaking: TestEventSeriesf Testgrid link: Reason for failure: Timeout: Anything else we need to know: To reproduce with stress: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
filed to address this issue.
contains the correct analysis of flakes (thanks a lot!), I commented on way of fixing it (which I'm not convinced about).