jiebi/CodeConvo huggingface dataset:
Code change:
"bytes" "fmt" "reflect" <ins> "regexp" </ins> "strings" "testing" "time"

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): describe psp Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): Environment: Doesn't matter. What happened: doesn't show PSP's fields: What you expected to happen: All PSP fields should be shown. How to reproduce it (as minimally and precisely as possible):
If you're agree with that than I (or :) ) could implement it.
yes, improve the describer. Look at the scc describer for formatting.
any ideas which SIG should own PSP?
In this case it should be sig-cli /sig cli
yeah, this is cli related. I'd go with sig-auth for actual behavior.
Code change:
// ValidateCSIDriverUpdate validates a CSIDriver. func ValidateCSIDriverUpdate(new, old *storage.CSIDriver) field.ErrorList { allErrs := apivalidation.ValidateObjectMetaUpdate(&new.ObjectMeta, &old.ObjectMeta, field.NewPath("metadata")) <ins> allErrs = append(allErrs, validateCSIDriverSpec(&new.Spec, field.NewPath("spec"))...) </ins> // immutable fields should not be mutated. allErrs = append(allErrs, apimachineryvalidation.ValidateImmutableField(new.Spec.AttachRequired, old.Spec.AttachRequired, field.NewPath("spec", "attachedRequired"))...) allErrs = append(allErrs, apimachineryvalidation.ValidateImmutableField(new.Spec.FSGroupPolicy, old.Spec.FSGroupPolicy, field.NewPath("spec", "fsGroupPolicy"))...) allErrs = append(allErrs, apimachineryvalidation.ValidateImmutableField(new.Spec.PodInfoOnMount, old.Spec.PodInfoOnMount, field.NewPath("spec", "podInfoOnMount"))...) allErrs = append(allErrs, apimachineryvalidation.ValidateImmutableField(new.Spec.VolumeLifecycleModes, old.Spec.VolumeLifecycleModes, field.NewPath("spec", "volumeLifecycleModes"))...) <del> allErrs = append(allErrs, apimachineryvalidation.ValidateImmutableField(new.Spec.StorageCapacity, old.Spec.StorageCapacity, field.NewPath("spec", "storageCapacity"))...) </del> allErrs = append(allErrs, validateTokenRequests(new.Spec.TokenRequests, field.NewPath("spec", "tokenRequests"))...) return allErrs

Related discussion:
text: Up to 1.21, that field is immutable. That means in practice, a CSIDriver object has to be deleted and then re-created with a different value instead. Mutation via delete/created is unnecessarily complex and as the only consumer of that field (the kube-scheduler) can handle mutation just fine (it'll always ask the informer cache for the current value), it's better to allow mutation.
/sig storage /assign
This is independent of allowing other fields to become mutable, but that might also make sense.
/triage accepted
Code change:
"github.com/google/gofuzz" ) <ins> func TestConverter_DefaultConvert(t *testing.T) { type A struct { Foo string Baz int } type B struct { Bar string Baz int } c := NewConverter() c.Debug = t c.NameFunc = func(t reflect.Type) string { return "MyType" } // Ensure conversion funcs can call DefaultConvert to get default behavior, // then fixup remaining fields manually err := c.Register(func(in *A, out *B, s Scope) error { if err := s.DefaultConvert(in, out, IgnoreMissingFields); err != nil { return err } out.Bar = in.Foo return nil }) if err != nil { t.Fatalf("unexpected error %v", err) } x := A{"hello, intrepid test reader!", 3} y := B{} err = c.Convert(&x, &y, 0, nil) if err != nil { t.Fatalf("unexpected error %v", err) } if e, a := x.Foo, y.Bar; e != a { t.Errorf("expected %v, got %v", e, a) } if e, a := x.Baz, y.Baz; e != a { t.Errorf("expected %v, got %v", e, a) } } </ins> func TestConverter_CallsRegisteredFunctions(t *testing.T) { type A struct { Foo string

Related discussion:
text: Files storing latest versions for minors are not updated since infix was to the version string. Example Similar issues can be found in 1.25 and 1.24 builds (last 1.23 build infix so it has not happened there yet): I expect the files to be overwritten with newer version of the build. Manually run build job for one of the minors. No response Not related. Not related. No response No response No response No response
I believe this may be also responsible for breaking kubemark tests: since they fail due to version mismatch
/sig release
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority high 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
Thanks for raising the issue! /cc who is working on before
I assume this will be fixed automatically with the next patches, because then we would compare with . Anyway, I think we should fix that intermediately by manually updating the version markers to match their correct version. I did that now for the bucket
We had to update the versions markers again, because those were pointing to two commits earlier and didn't include the Go updates. The latest version markers are: v1.24.12-35+ v1.25.8-37+ v1.26.3-41+
latest-1.27 has been affected by this as well. I updated it manually to v1.27.0-9+. See this thread for more details:
/triage accepted
This should be fixed now, closing it. Feel free to reopen if we missed anything.
This issue is still present, see this Slack thread for more details: /reopen
Reopened this issue. <detailsIn response to : This issue is still present, see this Slack thread for more details: /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
We have a similar situation with latest-1.28 which is currently pointing to: . This is one commit before the release commit: ! It's mostly like that the release step didn't update version markers, we should look into this.
Code change:
"github.com/google/gofuzz" ) <ins> func TestConverter_DefaultConvert(t *testing.T) { type A struct { Foo string Baz int } type B struct { Bar string Baz int } c := NewConverter() c.Debug = t c.NameFunc = func(t reflect.Type) string { return "MyType" } // Ensure conversion funcs can call DefaultConvert to get default behavior, // then fixup remaining fields manually err := c.Register(func(in *A, out *B, s Scope) error { if err := s.DefaultConvert(in, out, IgnoreMissingFields); err != nil { return err } out.Bar = in.Foo return nil }) if err != nil { t.Fatalf("unexpected error %v", err) } x := A{"hello, intrepid test reader!", 3} y := B{} err = c.Convert(&x, &y, 0, nil) if err != nil { t.Fatalf("unexpected error %v", err) } if e, a := x.Foo, y.Bar; e != a { t.Errorf("expected %v, got %v", e, a) } if e, a := x.Baz, y.Baz; e != a { t.Errorf("expected %v, got %v", e, a) } } </ins> func TestConverter_CallsRegisteredFunctions(t *testing.T) { type A struct { Foo string

Related discussion:
text: As of now, I'm going to manually update this version marker to unblock 1.28.1 patch release. I'll also take a look into this. /assign
The PR that fixed this issue got reverted so this is still relevant: /reopen
Reopened this issue. <detailsIn response to : The PR that fixed this issue got reverted so this is still relevant: /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
We're running into this issue again with stable-1.29 marker. It's currently pointing to which is It should instead point to I'm going to manually change it following the same procedure as the last time. Version marker updated to
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
/triage accepted
Same issue for 1.30, where I had to update the version marker manually again.
Code change:
package remote import ( <ins> "os" </ins> "testing" "time"

Related discussion:
text: Which jobs are flaking: periodics-kubernetes-bazel-test Which test(s) are flaking: //pkg/kubelet/cri/remote TestVersion Testgrid link: Reason for failure: Error: Received unexpected error: rpc error: code = Unavailable desc = transport is closing panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference Anything else we need to know: To reproduce with stress: go test -race -c ./pkg/kubelet/cri/remote stress - TestVersion Detailed logs
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 testing
I 'll give it a see and fix it :)
/assign
/remove-sig testing SIG node owns their unit tests. SIG testing owns the framework, infrastructure, etc.
/sig node
Code change:
"testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </ins> ) func TestNamespaceStrategy(t *testing.T) {

Related discussion:
text: There is a funny subtle behvaiour in get namespaces, in which if i call more than one time, it seems that the removal from Terminating state is accelarated. It seems this might indicate a bug, or maybe its not a bug and the eventual semantics of is a little funny sometimes. in any case, here's what we are seeing : 1) when i delete a namespace the first time usning kubectl, we get a state change to . that is correct, of course. 2) but ... if make the call a second time, then the same status line is immediately removed from . Expected behaviour : A second call to "kubectl delete ..." shouldn't have any effect on the timing of removal of a namespace from 'Terminating' state*... So i guess there is some "eventual consistency" subtle bug that is resolved by repeated calls to
suggests this may not be e bug, maybe its just the etcd eventual deleter thingy.
Looks to definitely be a bug. The 2nd delete seems to have interrupted the delete process and artifacts (like events) from the namespace still exist in etcd.
investigating...
oops, see the error, will submit a fix.
I have a fix, but need a test case, will submit PR tomorrow AM
Code change:
errCh.SendErrorWithCancel(err, cancel) return } <ins> klog.V(2).InfoS("Preemptor Pod preempted victim Pod", "preemptor", klog.KObj(pod), "victim", klog.KObj(victim), "node", c.Name()) </ins> } fh.EventRecorder().Eventf(victim, pod, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by a pod on node %v", c.Name()) }

Related discussion:
text: A V(2) log line that includes preemption details (preemptee and preemptor), somewhere here We used to have most of this information as part of the logging for Events. But we removed the preemptor from it as a security measure Logs can have pod names.
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 scheduling
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
/help-remove
Code change:
} interval := time.NewTicker(time.Millisecond * 500) defer interval.Stop() <del> done := make(chan bool, 1) </del> <ins> done := make(chan bool) </ins> go func() { time.Sleep(time.Minute * 2) <del> done <- true </del> <ins> close(done) </ins> }() for { select {

Related discussion:
text: It's at line 111 When the server stopped before timeout, the first goroutine will be block on because the receiver in the second goroutine is not exist. Changing to a buffered one may fix it. no goroutine leaks run related test with leak checker No response <detailsdev </details<detailsunknown </details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
/cc
It should close the channel rather than write to it, that's the easiest fix
Code change:
CLUSTER_DIR?=$(shell pwd)/../../../cluster/ <del> BASEIMAGE=debian:stable-slim TEMP_DIR:=$(shell mktemp -d -t conformanceXXXXXX) </del> <ins> # This is defined in root Makefile, but some build contexts do not refer to them KUBE_BASE_IMAGE_REGISTRY?=k8s.gcr.io ifeq ($(ARCH),amd64) BASEIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base:v2.1.3 else BASEIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base-${ARCH}:v2.1.3 endif RUNNERIMAGE?=gcr.io/distroless/base:latest TEMP_DIR:=$(shell mktemp -d -t conformance-XXXXXX) </ins> all: build

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be modified: image to be based on anything other than Docker Hub sourced Why is this needed: With Docker Hub rate-limit policy in-place, we probably should consider removing this dependency to stay in sync with other base images in Kubernetes project. Folks building their own binaries (i.e. with ) might run into this as well. Notes: Prior discussion happened on An idea from is to use the should probably be renamed to avoid confusion with k/release (h/t Currently, is set to , so migrating to may not be a drop-in move However, , so maybe we don't have to start from scratch /sig testing /area conformance /sig release (cc'ing because builds conformance image, though my quick search seem to show there isn't any build pipelines referencing )
/assign
do we still want to do this? I read somewhere that the images built in Google Cloud are being mirrored from Docker Hub, right? This would mean that the API rate limiting will not hit us any more.
Womp yeah I think DockerHub rate limit is not really the big motivator at this point. However, I think I still want to consider using distroless / go-runner to build and produce conformance image to reduce the noise from CVE scanning done in downstream places. What do you think?
Yeah I think this seems a valuable addition. Are you planning to work on this issue? :)
I will, though probably won't start until next week. If you have ideas and would like to start early feel free to go for it! Otherwise, I'd be happy to work on and deliver this.
Thank you Wilson! Feel free to ping again if you need any assistance. /assign
/triage accepted
one thing I need a little help with is to find a reference for using go-runner image that's used everywhere -- the one that I've found is inside conformance directory which seems to be different from what everyone else is using
We maintain a go-runner in k/release:
oops, I forgot to get back on this last week -- I meant to say that I need a reference for image which I can use as , so something like on Dockerfile. Is that a possible thing to do?
Code change:
CLUSTER_DIR?=$(shell pwd)/../../../cluster/ <del> BASEIMAGE=debian:stable-slim TEMP_DIR:=$(shell mktemp -d -t conformanceXXXXXX) </del> <ins> # This is defined in root Makefile, but some build contexts do not refer to them KUBE_BASE_IMAGE_REGISTRY?=k8s.gcr.io ifeq ($(ARCH),amd64) BASEIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base:v2.1.3 else BASEIMAGE?=${KUBE_BASE_IMAGE_REGISTRY}/build-image/debian-base-${ARCH}:v2.1.3 endif RUNNERIMAGE?=gcr.io/distroless/base:latest TEMP_DIR:=$(shell mktemp -d -t conformance-XXXXXX) </ins> all: build

Related discussion:
text: after searching around, I found this -- going to try and use and see how it works :smile:
Started a PR -- plenty of things I'd like to be discussed but we should probably have the discussions there
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale there is work in progress
Code change:
} } } <ins> // Providing HardPodAffinitySymmetricWeight in the policy config is the new and preferred way of providing the value. // Give it higher precedence than scheduler CLI configuration when it is provided. if policy.HardPodAffinitySymmetricWeight != 0 { f.hardPodAffinitySymmetricWeight = policy.HardPodAffinitySymmetricWeight } </ins> return f.CreateFromKeys(predicateKeys, priorityKeys, extenders) }

Related discussion:
text: ( noticed this) HardPodAffinitySymmetricWeight should be in the , not in KubeSchedulerConfiguration If/when fixing this, we need to be careful to do it in a backward-compatilble way.
Do you mean ? It seems scheduler policy config's args can not passed to FitPredicates; it need to update related interface. For the : mark to be deprecated and set scheduler policy config to HardPodAffinitySymmetricWeight if policy config is empty.
Are you working on this? if no, I can take it.
, nop; please go ahead.
/ / / , When reviewing the PR, there's one question on : the default value of is 1, which means the weight (1) will always add to priorities if term matched (), does it our expectation? And the user has to set it to 0 to disable it. IMO, the default value of should be 0.
The value 1 (instead of 0) was chosen so that if you say A must run with B, there is an automatic preference that B should run with A. This seems like reasonable behavior.
Thanks very much; reasonable case to me. But it seems we can not disable it: if set to 0, the default funcs will set it to default (1); similar result to un-set. Anyway, no user complain this now :).
Code change:
"time" "github.com/golang/glog" <del> "github.com/golang/protobuf/proto" </del> cadvisorfs "github.com/google/cadvisor/fs" cadvisorapiv2 "github.com/google/cadvisor/info/v2"

Related discussion:
text: In , we merged a work around for heapster panic We should get rid of the work around after heapster version is updated. /cc /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
runtimeapi "k8s.io/kubernetes/pkg/kubelet/api/v1alpha1/runtime" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" <ins> "k8s.io/kubernetes/pkg/kubelet/dockertools" </ins> "k8s.io/kubernetes/pkg/kubelet/qos" "k8s.io/kubernetes/pkg/kubelet/types" )

Related discussion:
text: What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Code change:
capabilities.Setup(kcfg.AllowPrivileged, privilegedSources, 0) credentialprovider.SetPreferredDockercfgPath(kcfg.RootDirectory) <ins> glog.V(2).Infof("Using root directory: %v", kcfg.RootDirectory) </ins> builder := kcfg.Builder if builder == nil {

Related discussion:
text: During the startup process of kubelet, we have Since we have following Code segment 1 and 2 seems dup to me. Am i getting this wrong?
Code change:
cluster/addons/fluentd-elasticsearch/es-image cluster/images/etcd/attachlease <ins> cluster/images/etcd/rollback </ins> cmd/gendocs cmd/genkubedocs cmd/genman

Related discussion:
text: ci-kubernetes-e2e-gce-device-plugin-gpu.Overall ci-kubernetes-e2e-gce-device-plugin-gpu.Pod kubetest.Up Intermittently since 02/23 No response No response /sig testing /sig release
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
/cc /sig node BTW, would you help to confirm if this is a release cut blocker? We plan to release 1.30.0-alpha.3 on Tuesday 27th February 2024.
It passed! Maybe it was some infra issues?
Failed again. /sig k8s-infra
Many recreating of nodes in log.
This is caused by infra flaky.
The problem is
This job only runs one test and GPU instances are hard to find we don’t need many of those instances for this job, can we please change this job to only use 2 workers?
/cc
tests failed in a recent run. It failed the first time. The Job failure now changed to test case failing today. It failed 4 times in a row.
/assign
I launched a test run, logged into the master node and took the kubeconfig and found the following: Relevant bit
Link some related updates recently on this job.
The error above in is weird to me. It said No firmware image found . In successful run before, like (02-27), there are no such failure logs. failure in only kubelet log shows the pod crashed and restarted for many times. No pod log or containerd log.
After , the CI is not always failing now and 4 in a row.
/close
Closing this issue. <detailsIn response to : /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
/reopen as keeps flaking
Reopened this issue. <detailsIn response to : /reopen as keeps flaking Instructions for interacting with me using PR comments are available .