jiebi/CodeConvo huggingface dataset:
Change:
}, expected: []*batchv1.Job{}, }, <ins> { name: "test getting jobs whose labels do not match job template", cronJob: &batchv1.CronJob{ ObjectMeta: metav1.ObjectMeta{Namespace: "foo-ns", Name: "fooer"}, Spec: batchv1.CronJobSpec{JobTemplate: batchv1.JobTemplateSpec{ ObjectMeta: metav1.ObjectMeta{Labels: map[string]string{"key": "value"}}, }}, }, jobs: []runtime.Object{ &batchv1.Job{ObjectMeta: metav1.ObjectMeta{ Namespace:       "foo-ns", Name:            "foo-fooer-owner-ref", Labels:          map[string]string{"key": "different-value"}, OwnerReferences: []metav1.OwnerReference{{Name: "fooer", Controller: &trueRef}}}, }, &batchv1.Job{ObjectMeta: metav1.ObjectMeta{ Namespace:       "foo-ns", Name:            "foo-other-owner-ref", Labels:          map[string]string{"key": "different-value"}, OwnerReferences: []metav1.OwnerReference{{Name: "another-cronjob", Controller: &trueRef}}}, }, }, expected: []*batchv1.Job{{ ObjectMeta: metav1.ObjectMeta{ Namespace:       "foo-ns", Name:            "foo-fooer-owner-ref", Labels:          map[string]string{"key": "different-value"}, OwnerReferences: []metav1.OwnerReference{{Name: "fooer", Controller: &trueRef}}}, }}, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {

Discussion:
Changing the label on a job template in a CronJob causes any Jobs held by the successful/failed history parameters to stop being tracked, so they never get cleaned up. Jobs with labels that don't match the (upgraded) CronJob, but still have an owner reference, should be subject to the history limit. a CronJob with a job template containing label , and non-zero history limit the CronJob to run and generate some Jobs (default 3 successful, 1 failed) the CronJob with a job template containing label the CronJob to run and generate some more Jobs there are more than 3 successful Jobs/1 failed Job! I believe this is the relevant code: The CronJob controller finds Jobs that it should care about by matching on the labels in the job template, this obviously breaks if the labels in the job template change. 21 Self-hosted No response No response No response No response_
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
Experiencing another side-effect of this bug. If job template labels are updated while a cronjob has status (a scheduled job is running), then that cronjob gets stuck in . The cause seems to be the same as describes: once the job template labels are updated, cronjob controller V2 loses track of the jobs with the old labels, and therefore never updates the status of that active cronjob to indicate that the scheduled job has completed.
/assign
Change:
group *APIGroup } <ins> const ( StatusUnprocessableEntity = 422 ) </ins> // Handle returns a Handler function that expose the provided storage interfaces // as RESTful resources at prefix, serialized by codec, and also includes the support // http resources.

Discussion:
I0825 04:43:42. ] GET /logs: (51.111us) 301 goroutine 315 [running]: (respLogger).WriteHeader(0xc21036a240, 0x12d) +0x9c net/http.Redirect(0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680, 0xc2102bbd60, 0x6, ...) +0x436 net/http.(redirectHandler).ServeHTTP(0xc2103089c0, 0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680) +0x5e net/http.(ServeMux).ServeHTTP(0xc2102f4030, 0x7f4d60b7ed80, 0xc21036a240, 0xc2101a7680) +0x163 ·002(0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x197 net/http.HandlerFunc.ServeHTTP(0xc210309180, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x40 (defaultAPIServer).ServeHTTP(0xc210308a60, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x51 net/http.serverHandler.ServeHTTP(0xc210317960, 0x7f4d60b7ed48, 0xc2102c5140, 0xc2101a7680) +0x16e net/http.(conn).serve(0xc2102b2180) +0x7b7 created by net/http.(Server).Serve +0x28b
Is it just that 301 isn't in the list of things to not show a stacktrace for?
Change:
tokens[privilegedLoopbackToken] = &user.DefaultInfo{ Name:   user.APIServerUser, UID:    uuid.New().String(), <del> Groups: []string{user.SystemPrivilegedGroup}, </del> <ins> Groups: []string{user.SystemPrivilegedGroup, user.AllAuthenticated}, } tokens[UnprivilegedUserToken] = &user.DefaultInfo{ Name:   "unprivileged", UID:    uuid.New().String(), Groups: []string{user.AllAuthenticated}, </ins> } tokenAuthenticator := authenticatorfactory.NewFromTokens(tokens, controlPlaneConfig.GenericConfig.Authentication.APIAudiences) if controlPlaneConfig.GenericConfig.Authentication.Authenticator == nil { <del> controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticatorunion.New(tokenAuthenticator, authauthenticator.RequestFunc(alwaysEmpty)) </del> <ins> controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticatorunion.New(tokenAuthenticator, authauthenticator.RequestFunc(unsecuredUser)) </ins> } else { controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticatorunion.New(tokenAuthenticator, controlPlaneConfig.GenericConfig.Authentication.Authenticator) }

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
//nolint:unused // U1000 see comment above, we know it's unused normally. func (fakeTestDeps) SnapshotCoverage() {} <ins> //nolint:unused // U1000 see comment above, we know it's unused normally. func (fakeTestDeps) InitRuntimeCoverage() (mode string, tearDown func(string, string) (string, error), snapcov func() float64) { return "", nil, nil } </ins>

Discussion:
Hello k8s folks: This code here: is making a call to the function , which is documented as not maintaining the Go 1 compatibility guarantee. Here is the header comment for MainStart: Filing this issue to let you know that in the upcoming Go release (1.23) the signature of MainStart is indeed changing; there is a new method on the testDeps interface. If you could please add this new method to your dummy testDeps interface (as in the previous patch that would be great. Thanks. from the golang team. N/A N/A No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
Closing this issue. <detailsIn response to : a better place to ask would be on the support channels. please see: /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
Reopened this issue. <detailsIn response to : /reopen </details
/sig release
/assign mauri870
/triage accepted
/sig testing
many thanks for the report. release folks, let's start the go1.23 tracking issue we can link this to as a PR that will need picking to release branches to make them ready for eventual update to 1.23
cc
Change:
func (e *eventBroadcasterImpl) StartStructuredLogging(verbosity klog.Level) watch.Interface { return e.StartEventWatcher( func(e *v1.Event) { <del> klog.V(verbosity).InfoS("Event occurred", "object", klog.KRef(e.InvolvedObject.Namespace, e.InvolvedObject.Name), "kind", e.InvolvedObject.Kind, "apiVersion", e.InvolvedObject.APIVersion, "type", e.Type, "reason", e.Reason, "message", e.Message) </del> <ins> klog.V(verbosity).InfoS("Event occurred", "object", klog.KRef(e.InvolvedObject.Namespace, e.InvolvedObject.Name), "fieldPath", e.InvolvedObject.FieldPath, "kind", e.InvolvedObject.Kind, "apiVersion", e.InvolvedObject.APIVersion, "type", e.Type, "reason", e.Reason, "message", e.Message) </ins> }) }

Discussion:
I used to use 1.171 standalone Kubelet mode without an API server for my cluster. Because I’m not using API server, I can only get container events from Kubelet logs. But after I upgrade Kubelet to 1.20.1, I found that the log format is changed and Kubelet log is no longer logging container info(“FieldPath” field in logs) for events logs due to this change So with a newer version Kubelet, I cannot know which container those events belong to from Kubelet logs. container info(“FieldPath” field) should be back to Kubelet event logs Can reproduce it with any standalone Kubelet version after 1.18.20. I also want to what’s the best practice to get events for standalone Kubelet? Should “FieldPath” field add back to log? or is there any plan to add something like an “event server”, so users can configure and use it to get events for standalone Kubelet easier? 20.1 N/A <details</details<details</details<details</details<details</details
/sig node
seems to only change the log style. In this example, the pod name is still included in the log. /cc /sig instrumentation
/wg structured-logging
Pod name is still there, but the "FieldPath" field which includes container name is missing Old version log:
To add back FieldPath, change to An example of an event for pod: The log included name/namespace/kind/apiVersion/
/triage accepted
would you confirm this is expected or a regression?
/assign
Gentle ping on this, this is a blocking issue, without a fix, we need to stay with v1.18. Do we have a plan to fix this? or maybe I can help to fix it. Thanks
Removing fields like "fieldPath" was not intended. It should be ok to reintroduce this field to logs like showed in This is however not a bug as we don't provide any guarantee about log contents. Feel free to send a PR that will add this field back. /kind feature
/remove-kind bug
Change:
"hybrid_network.go", "memory_limits.go", "networking.go", <ins> "security_context.go", </ins> "service.go", "volumes.go", ],

Discussion:
We need test cases that cover running as Windows users in containers. Windows uses a different field WindowsContainerSecurityContext.runasusername () They should only run with the ginkgo focus set. This will replace the similar test cases on Linux: /kind test /sig windows
/good-first-issue
/assign
GitHub didn't allow me to assign the following users: michellemcone. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I can't assign this to Michelle yet, so I'll park it on myself for now. If it's not done in a few weeks and someone else wants to take it, drop a comment here.
/milestone v1.14
/remove good-first-issue It looks like this may not be ready for testing. has the first half of the feature implemented, but it's still incomplete.
/assign So, when the API for `? Although this come at a later date, since it would need to be implemented in kubelet first.
GitHub didn't allow me to assign the following users: bclau. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign </details
/good-first-issue remove
/clear milestone
/milestone clear /kind cleanup
/remove-good-first-issue
/milestone v1.16
Hello! I'm part of the bug triage team for the 1.16 release cycle and considering this issue is tagged for 1.16, but not updated for a long time, I'd like to check its status. The code freeze is starting on August 29th (about 1.5 weeks from now), which means that there should be a PR ready (and merged) until then. Do we still target this issue to be fixed for 1.16? If not please re-tag the issue to the planned milestone.
This issue is addressed by: This should be included in 1.16.
Change:
sha256 = "05ab3937bc68562e989dc143362ec4d4275262ba9f359338aed720fc914457a5", url = "https://storage.googleapis.com/kubernetes-release/network-plugins/cni-amd64-0799f5732f2a11b329d9e3d51b9c8f2e3759f2ff.tar.gz", ) <ins> docker_pull( name = "debian-iptables-amd64", digest = "sha256:adde513f7b3561042cd2d2af4d2d355189bbb2f579584b5766e7d07be4f7e71e",  # v7 registry = "gcr.io", repository = "google-containers/debian-iptables-amd64", ) </ins>

Discussion:
BUG REPORT Kubernetes version 2 Environment: Install tools: What happened: The code in takes care to supply the flag so it will wait on a lock to avoid interference between multiple processes modifying the table. If you read the source you discover it does this by creating a file . However, when is running in a container, is in a local filesystem, so it is not able to lock against processes running on the host or in other containers. And before you decide that the answer is to mount from the host, look at all the issues around leaking netns, e.g. Credit for pointing this out to me. Credit for pointing out locking functionality was to a few months back
Ironically, this is caused by a bugfix that moved to file-based locking. Previously, iptables would lock by reserving an abstract unix socket, which is tied to the network namespace.
Some discussion also in and following comments.
I experimented with this: but it didn't work on CoreOS, as the host wasn't using a version of iptables that used the file lock yet. Just ended up creating a directory call
I guess I should file this as an issue against kubeadm and any of the other sources of kube-proxy container config.
/assign
Should we leave this open (waiting for ... ?)
Waiting for I guess... (which I'm reviewing now)
i think this should not be marked as complete until the kubeadm fixes are in.
/reopen
/close fix in
Change:
logReduction: logreduction.NewLogReduction(identicalErrorDelay), } <del> if err := service.determineAPIVersion(conn); err != nil { </del> <ins> if err := service.determineAPIVersion(conn, endpoint); err != nil { </ins> return nil, err }

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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 node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
# See the OWNERS docs at https://go.k8s.io/owners <del> maintainers: - adityadani </del> <ins> approvers: - lpabon - saad-ali - rootfs reviewers: - lpabon - saad-ali - rootfs </ins>

Discussion:
Found this when trying to see which vendored dependencies does not use a proper tag (and is using a random SHA). The dependency is very old and there have been a lot of updates to it: Looks like the However there does not seem to be anyone around to take care of the portworx plugin. Is it time to deprecate it? is anyone using it? /sig storage
cc ?
/area code-organization
Hello The portworx volume plugin is definitely in use. The portworx volume plugin doesn't need frequent updates since the plugin acts as a simple client to all provisioning calls. In the same view, the vendored openstorage package doesn't need to be updated too. The server side implementation in Portworx handles all the latest Portworx features.
cc:
in that case, can you please update the dependency to a specific tag instead of a random SHA?
/assign updated the title of the issue as well
my request is not for a new release or tag in libopenstorage/openstorage repository. Just to update the SHA we use in our k/k repository to one of the released versions ( ). This is not asking or demanding anything to be done in libopenstorage/openstorage, just that we should update what we use from there (and avoid a random SHA). We are trying to do this for all vendored libraries (one by one … slowly as part of the sig-arch code organization sub project, so it’s not a random request)
/assign
GitHub didn't allow me to assign the following users: lpabon. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
After a chat with - apparently this request is coming across the wrong way I am closing this out as it seems to add a over head /close
Closing this issue. <detailsIn response to : After a chat with - apparently this request is coming across the wrong way /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:
genericfeatures.APIListChunking: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.32 <del> genericfeatures.APIPriorityAndFairness: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31 </del> genericfeatures.APIResponseCompression: {Default: true, PreRelease: featuregate.Beta}, genericfeatures.APIServerIdentity: {Default: true, PreRelease: featuregate.Beta},

Discussion:
Priority and Fairness is going GA in 1.29, the feature has been marked stable and the feature gate has been locked to default. See In 1.31, we need to remove the feature gate.
/kind bug /sig api-machinery /cc
/assign
/triage accepted
Change:
Force           bool ServerSideApply bool ForceConflicts  bool <ins> genericclioptions.IOStreams </ins> } var _ Object = &InfoObject{}

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 tried to with a Deployment spec that was roughly shaped like this (note that the is invalid, since it should be a list of instead of ). This caused kubectl to fail to create a three-way patch and panic. <details<summaryClick here for the stacktrace</summary</detailsWhat you expected to happen: An error is returned How to reproduce it (as minimally and precisely as possible): Create a deployment, then try to diff using the YAML provided above (make sure to replace the name and namespace) Anything else we need to know?: The panic occurs on this line because is nil: It's set to nil here: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
Raised a pr which may fix this bug.
Change:
container "google.golang.org/api/container/v1" "google.golang.org/api/googleapi" "google.golang.org/cloud/compute/metadata" <del> "gopkg.in/gcfg.v1" </del> ) const (

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} What happened: Dynamic provisioned volumes in different zones with master failed to deleted What you expected to happen: Since the volume can be dynamic provisioned when the zones differs from master, then it should be deleted after delete the PVC which created them. How to reproduce it (as minimally and precisely as possible): up an all-in-one cluster. The instance is created in zone us-central1-a. several storageClass. One in zone us-central1-a. Another in zone us-central1-b. several PVC. pvc1 using storageClass1(zone us-central1-a), pvc2 using storageClass2(zone us-central1-b). PV/volume were provisioned in proper size/mode/zone. PVCs. with volume in zone us-central1-b failed with error can not find the volume.

Anything else do we need to know: Name: pvc--70d1-11e6-b17e- Labels: failure- failure- Status: Failed Claim: default/pvc5 Reclaim Policy: Delete Access Modes: RWO Capacity: 4Gi Message: Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" Source: Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) PDName: kubernetes-dynamic-pvc--70d1-11e6-b17e- FSType: Partition: 0 ReadOnly: false Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message 11m 11m 1 {persistentvolume-controller } Warning VolumeFailedDelete Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" creationTimestamp: '2016-09-01T22:49:26.439-07:00' description: '{"":"pvc--70d1-11e6-b17e-","":"pvc5","":"default"}' id: '' kind: compute#disk name: kubernetes-dynamic-pvc--70d1-11e6-b17e- selfLink: sizeGb: '4' status: READY type: zone:
Kubernetes can delete GCE PDs only in zones it manages. I.e. either in the same zone as the master or, when multizone is enabled in GCE config, in all zones in the same region. This should not be allowed in the first place. Kubernetes should not create disks outside zones it manages and report an error instead. So... please use following , it will be allow creation/deletion of disks in all zones in us-central1 region: And I'll fix Kubernetes to report an error when creating a disk in all other zones.