jiebi/CodeConvo huggingface dataset:
Change:
Expect(err).NotTo(HaveOccurred()) } <ins> func setupLocalVolumeProvisionerMountPoint(config *localTestConfig, volumePath string) { By(fmt.Sprintf("Creating local directory at path %q", volumePath)) mkdirCmd := fmt.Sprintf("mkdir %v -m 777", volumePath) err := framework.IssueSSHCommand(mkdirCmd, framework.TestContext.Provider, config.node0) Expect(err).NotTo(HaveOccurred()) By(fmt.Sprintf("Mounting local directory at path %q", volumePath)) mntCmd := fmt.Sprintf("sudo mount --bind %v %v", volumePath, volumePath) err = framework.IssueSSHCommand(mntCmd, framework.TestContext.Provider, config.node0) Expect(err).NotTo(HaveOccurred()) } func cleanupLocalVolumeProvisionerMountPoint(config *localTestConfig, volumePath string) { By(fmt.Sprintf("Unmounting the test mount point from %q", volumePath)) umountCmd := fmt.Sprintf("sudo umount %v", volumePath) err := framework.IssueSSHCommand(umountCmd, framework.TestContext.Provider, config.node0) Expect(err).NotTo(HaveOccurred()) By("Removing the test mount point") removeCmd := fmt.Sprintf("rm -r %s", volumePath) err = framework.IssueSSHCommand(removeCmd, framework.TestContext.Provider, config.node0) } </ins> func createServiceAccount(config *localTestConfig) { serviceAccount := v1.ServiceAccount{ TypeMeta:   metav1.TypeMeta{APIVersion: "v1", Kind: "ServiceAccount"},

Discussion:
The local PV provisioner is being updated to discover only real mount points (and not directories), that resolves some other related issues. The related e2e tests using the local PV provisioner need to be updated accordingly.
/assign
/sig storage
FYI:
Change:
"k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/validation" "k8s.io/apimachinery/pkg/util/validation/field" <ins> genericapirequest "k8s.io/apiserver/pkg/endpoints/request" </ins> "k8s.io/apiserver/pkg/storage/value" kmstypes "k8s.io/apiserver/pkg/storage/value/encrypt/envelope/kmsv2/v2alpha1" "k8s.io/apiserver/pkg/storage/value/encrypt/envelope/metrics"

Discussion:
Add additional logging at level that associates UID with the metadata from the request. xref: /sig auth
/triage accepted
/milestone v1.26
Mind if I take a look at this? /assign
Hello I am wondering how's this coming along. Is there anything I can help with?
Sorry. I got a bit occupied with a different project.. Will have a PR opened for this for review tomorrow.. I am trying to find a way to inject the Verbs into log. But haven't found the right way to include that into the context.. Any suggestion on what can be done?
any suggestion on what is the best way to get the additional metadata for verbs into this log? Move that info across using ?
Hello , bug triage team here, just wanted to touch base with you for updates on this ticket. Thanks!
Thanks! This is being worked on and is still on track for .
There is a Pull request opened on this already as well. But Waiting on some clarification to see if that needs additional changes.
/reopen /assign /unassign
Reopened this issue. <detailsIn response to : /reopen /assign /unassign 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
/milestone v1.27
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi Bug Triage Team for v1.27 here o/ Just wanted to touch base with you for updates on this ticket. Thanks!
I am not working on this anymore Carlos. This was re-assigned
This is tracked for . I've linked the PR.
Change:
ContainersToStart: []int{1}, }, }, <ins> "Restart the container if the container is in created state": { mutatePodFn: func(pod *v1.Pod) { pod.Spec.RestartPolicy = v1.RestartPolicyNever }, mutateStatusFn: func(status *kubecontainer.PodStatus) { status.ContainerStatuses[1].State = kubecontainer.ContainerStateCreated }, actions: podActions{ SandboxID:         baseStatus.SandboxStatuses[0].Id, ContainersToKill:  map[kubecontainer.ContainerID]containerToKillInfo{}, ContainersToStart: []int{1}, }, }, </ins> } { pod, status := makeBasePodAndStatus() if test.mutatePodFn != nil {

Discussion:
It was consistently observed in a testing environment that a node-critical pod failed to start. event was present but was missing( is an init container). Also the following error was present but strangely only once: After some digging it seemed throwing an error matched the observations above. Eventually the init container and the pod to start The following tests in recreate the problem by and show how depending on the behavior is different. When the feature gate is enabled the last init container gets stuck in and never gets started. Therefore the pod get's stuck and never progresses The problem seems to stem from: There case get's skipped and the created container is expected to get started by the previous one by the following lines or But the provided tests show that this does not happen. Also if there is only one init container with the following logic should execute but won't because in this case this get's executed <details</details<details</details<details</details<details</details<details</details<details</details
/sig node can you help checking this issue report as according to it is a regression introduced with Thanks in advance!
I'll take a look. /assign
I guess this is a valid bug. /triage accepted /priority important-soon Can you provide a more specific scenario for this? Why do container runtime fail to start the container? (How can I reproduce it in e2e test?)
^ I guess this is the wrong assumption. If the container is in the state, the kubelet should resync it.
During node bootstrapping we had a bug where got restarted. So it is possible the following to happen: container gets created -restarts -container fails to start
We have a similar case. I have not yet looked at how containerd behaves at the moment, because it happens rarely and only at node startup. Pod stuck in the status. In the suppress status we have the following message: Alse we have the next events: Node characteristics: And it's like the error is reproduced on 1.29. The neighbouring cluster with k8s 1.28 is not affected by this problem
we have observed a similar behaviour but intermittently while upgrading our k8s cluster from k8s 1.29.0 to 1.29.6.

During upgrade process, when the node gets rebooted the "calico-node" pod of that node got stuck with below error forever until i restart the pod manually. Note: We are not observing this every time. Please let me know for any additional info required.
/cc
Change:
return nil } <del> func NewFakeProxier(ipt utiliptables.Interface, ipvs utilipvs.Interface, ipset utilipset.Interface, nodeIPs []net.IP, excludeCIDRs []string) *Proxier { </del> <ins> func NewFakeProxier(ipt utiliptables.Interface, ipvs utilipvs.Interface, ipset utilipset.Interface, nodeIPs []net.IP, excludeCIDRs []*net.IPNet) *Proxier { </ins> fcmd := fakeexec.FakeCmd{ CombinedOutputScript: []fakeexec.FakeCombinedOutputAction{ func() ([]byte, error) { return []byte("dummy device have been created"), nil },

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:
return r.store.Delete(ctx, name, options) } <ins> func shouldHaveOrphanFinalizer(options *metav1.DeleteOptions, haveOrphanFinalizer bool) bool { if options.OrphanDependents != nil { return *options.OrphanDependents } if options.PropagationPolicy != nil { return *options.PropagationPolicy == metav1.DeletePropagationOrphan } return haveOrphanFinalizer } func shouldHaveDeleteDependentsFinalizer(options *metav1.DeleteOptions, haveDeleteDependentsFinalizer bool) bool { if options.OrphanDependents != nil { return *options.OrphanDependents == false } if options.PropagationPolicy != nil { return *options.PropagationPolicy == metav1.DeletePropagationForeground } return haveDeleteDependentsFinalizer } </ins> func (e *REST) ConvertToTable(ctx context.Context, object runtime.Object, tableOptions runtime.Object) (*metav1beta1.Table, error) { return e.store.ConvertToTable(ctx, object, tableOptions) }

Discussion:
What happened: I created a namespace with finalizer, and then tried to delete it: The namespace can be deleted, and the finalizer is removed by garbage collection controller: What you expected to happen: Since kubectl species , it is not an orphaning operation, the finalizer should be removed in namespace store. How to reproduce it (as minimally and precisely as possible): Same as what I observed: a namespace. finalizer. . Anything else we need to know?: Environment: Kubernetes version (use ): HEAD
/sig api-machinery
cc
Discussion on slack:
Change:
if _, err := serviceaccount.ReadPrivateKey(f.Name()); err != nil { t.Fatalf("error reading private ECDSA key: %v", err) } <ins> if err := ioutil.WriteFile(f.Name(), []byte(ecdsaPrivateKeyWithParams), os.FileMode(0600)); err != nil { t.Fatalf("error writing private key to tmpfile: %v", err) } if _, err := serviceaccount.ReadPrivateKey(f.Name()); err != nil { t.Fatalf("error reading private ECDSA key with params: %v", err) } </ins> } func TestReadPublicKeys(t *testing.T) {

Discussion:
Kubernetes version Serverversion 1.5.2 (running Hyperkube v1.5.2coreos.1 ()) Environment: Bare-Metal Coreos 1235.6.0 (Kernel 4.7.3-coreos-r2) What happened: kube-controller-manager with ecdsa key fails to start F0127 09:59:04. 1 ] error running controllers: Error reading key for service account token controller: error reading private key file data does not contain a valid RSA or ECDSA private key The key is valid (and works with e.g. the api-server) Command used to create the key:
the issue is the block. removing that (invoke openssl with to omit it from the start) will allow the key to be consumed. will fix in 1.6 to ignore that block when reading the private key block
Change:
"${SED}" -i '/CROSS_BUILD_/d' Dockerfile fi <del> docker buildx build --progress=plain --no-cache --pull --output=type="${output_type}" --platform "${os_name}/${arch}"  </del> <ins> # `--provenance=false --sbom=false` is set to avoid creating a manifest list: https://github.com/kubernetes/kubernetes/issues/123266 docker buildx build --progress=plain --no-cache --pull --output=type="${output_type}" --platform "${os_name}/${arch}" --provenance=false --sbom=false  </ins> --build-arg BASEIMAGE="${base_image}" --build-arg REGISTRY="${REGISTRY}" --build-arg OS_VERSION="${os_version}"  -t "${REGISTRY}/${image}:${TAG}-${suffix}" -f "${dockerfile_name}"  --label "image_version=${TAG}" --label "commit_id=${GIT_COMMIT_ID}" 

Discussion:
agnhost was updated to v2.46 in: However, is failing: . exporting to image exporting layers exporting layers 2.9s done exporting manifest sha256:db8e9d1930d4799d474ea9228d4957d54053c107e10385d77021ef44f567fc69 done exporting config sha256:037153f61da4211d6ec5f00f694639ce15a0bbebf12fa5c86eea059fc3c0b07c done exporting attestation manifest sha256:744b616c276ff7f6518476765c2457e0b2664225ef798ce7e93874450807310b exporting attestation manifest sha256:744b616c276ff7f6518476765c2457e0b2664225ef798ce7e93874450807310b 0.0s done exporting manifest list sha256:29bf785c1a8338d5f7a8be8cae8a2435b94370eecbaa586a61e08454095940cb done pushing layers pushing layers 5.9s done pushing manifest for pushing manifest for 4.3s done DONE 13.2s /workspace/test/images /workspace/test/images/agnhost /workspace/test/images is a manifest list make: * [Makefile:43: all-build-and-push] Error 1 ERROR ERROR: build step 0 "" failed: step exited with non-zero status: 2
2024/02/13 15:34:04 Failed to run some build jobs: [error running [gcloud builds submit --verbosity info --config --substitutions PULLBASEREF=master,PULLBASESHA=,WHAT=agnhost,GITTAG=v20240213-v1.30.0-alpha.

1-173-gc3b2295c3a --project k8s-staging-e2e-test-images --gcs-log-dir gs://k8s-staging-e2e-test-images-gcb/logs --gcs-source-staging-dir gs://k8s-staging-e2e-test-images-gcb/source gs://k8s-staging-e2e-test-images-gcb/source/-7566-469c-a5a0-]: exit status 1] N/A 2024-02-14 No response No response_ /sig testing
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
PR:
Change:
serv.Flags |= utilipvs.FlagPersistent serv.Timeout = uint32(svcInfo.StickyMaxAgeSeconds()) } <ins> // Set the source hash flag needed for the distribution method "mh" if proxier.ipvsScheduler == "mh" { serv.Flags |= utilipvs.FlagSourceHash } </ins> // There is no need to bind Node IP to dummy interface, so set parameter `bindAddr` to `false`. if err := proxier.syncService(svcPortNameString, serv, false, bindedAddresses); err == nil { activeIPVSServices[serv.String()] = true

Discussion:
The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)
Change:
}, CapacityKb: int64(diskManager.volumeOptions.CapacityKB), } <ins> vdm := object.NewVirtualDiskManager(datastore.Client()) </ins> requestTime := time.Now() // Create virtual disk task, err := vdm.CreateVirtualDisk(ctx, diskManager.diskPath, datastore.Datacenter.Datacenter, vmDiskSpec)

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 some cases, a create volume request can succeed in vSphere but time out in the vSphere storage plugin. This request will be retried, but fails with on subsequent attempts. As a result, the PersistentVolume object never gets created, and the pod requesting it never starts. Recovery requires manual steps. What you expected to happen: Since vSphere successfully created the volume, the storage plugin should reconcile and allow the PersistentVolume to get created. How to reproduce it (as minimally and precisely as possible): This is difficult to reproduce because it is caused by specific timing between vSphere and kubernetes. For testing, I a line of code to [][1] to inject failures after vSphere created the volume. [1]: 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 storage
Fixed by
Change:
} EOF <del> # Configuration for k8s services that redirect logs to /var/log/<service>.log # files. Whenever logrotate is ran, this config will: </del> <ins> # Configure log rotation for all logs in /var/log, which is where k8s services # are configured to write their log files. Whenever logrotate is ran, this # config will: </ins> # * rotate the log file if its size is > 100Mb OR if one day has elapsed # * save rotated logs into a gzipped timestamped backup # * log file timestamp (controlled by 'dateformat') includes seconds too. This

Discussion:
GCI log rotation configuration missed "" file. We should just configure log rotation to rotate all "*.log" files in /var/log.
I cherrypicked your change last night. Please do what you need to do to confirm this is resolved.
Thank you, will do.
Verified. Closing issue.
Change:
if err != nil { glog.Fatalf("Failed to make client: %v", err) } <ins> namespace := api.NamespaceSystem envNamespace := os.Getenv("NAMESPACE") if envNamespace != "" { if _, err := c.Namespaces().Get(envNamespace); err != nil { glog.Fatalf("%s namespace doesn't exist: %v", envNamespace, err) } namespace = envNamespace } </ins> var elasticsearch *api.Service // Look for endpoints associated with the Elasticsearch loggging service. // First wait for the service to become available. for t := time.Now(); time.Since(t) < 5*time.Minute; time.Sleep(10 * time.Second) { <del> elasticsearch, err = c.Services(api.NamespaceSystem).Get("elasticsearch-logging") </del> <ins> elasticsearch, err = c.Services(namespace).Get("elasticsearch-logging") </ins> if err == nil { break }

Discussion:
Now elasticsearchloggingdiscovery will only look for the endpoints in kube-system namespace due to hard-coded api.NamespaceSystem value. Maybe let user to decide in which namespace elasticsearchloggingdiscovery binary will look for endpoints ?
Change:
} else { claim.Labels = set.Spec.Selector.MatchLabels } <del> claims[templates[i].Name] = claim </del> <ins> claims[templates[i].Name] = *claim </ins> } return claims }

Discussion:
The kube-controller-manage may crash when processing StatefulSet with spec.podManagementPolicy is Parallel. With logs: we expect the kube-controller-manage will work well. The following example can reproduce this problem: After digging into the source code, we found that when using the pod management policy, the statefulset controller will use to start parallel processing. But the which is called during parallel processing may directly update the claims' labels without a lock. This finally causes a concurrent map-accessing problem. <details</details<details</details<details</details<details</details<details</details<details</details
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 apps
Thanks for the report. Do we know when this issue was introduced? cc
Maybe it was imported by this pr
We can reproduce this issue in unit testing.
The reported versions is and it seems that PR got backported further /priority important-soon
/assign
The original report looks like could have introduced it, yes. I wonder if we intentionally modify template without creating a copy (and as it seems, assign the exact same labels every time we use this template for any pod): Regardless, that was probably safe before the pod creations were parallelized. I don't think the proposed unit test catches the bug (more on that below), but we can probably reproduce it by timing pod state transitions so that many pods are simultaneously pending and missing a PVC. I ran this test on (before the cherry-pick of parallel statefulset scaling), and it also failed. This is because the test itself introduces a concurrent map write. It probably doesn't replicate the issue, and I don't think it can be merged, as it'll fail even if the original PR is reverted. For reproduction we'd need to catch a concurrent write without adding one in test code, just as it happened based on the original report.
Turns out we never tested this path at all, since the test PVC didn't have any labels of its own.

After adding labels, existing tests are sufficient to detect race condition. PR showing that improved test detects the issue: PR with fix and improved test:
Sweet! thanks !
Change:
result := c.client.clientBase.Put(). AbsPath(path). <del> Namespace(c.namespace). </del> <ins> NamespaceIfScoped(c.namespace, c.namespace != ""). </ins> Resource(gvr.Resource). Name(scale.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: