jiebi/CodeConvo huggingface dataset:
Change:
func validateClassParameters(ref *resource.ResourceClassParametersReference, fldPath *field.Path) field.ErrorList { var allErrs field.ErrorList <del> if ref != nil { if ref.Kind == "" { allErrs = append(allErrs, field.Required(fldPath.Child("kind"), "")) </del> <ins> if ref == nil { return allErrs } // group is required but the Core group is the empty value, so it can not be enforced. if ref.APIGroup != "" { for _, msg := range utilvalidation.IsDNS1123Subdomain(ref.APIGroup) { allErrs = append(allErrs, field.Invalid(fldPath.Child("apiGroup"), ref.APIGroup, msg)) </ins> } <del> if ref.Name == "" { allErrs = append(allErrs, field.Required(fldPath.Child("name"), "")) </del> <ins> } if ref.Kind == "" { allErrs = append(allErrs, field.Required(fldPath.Child("kind"), "")) } else { for _, msg := range pathvalidation.IsValidPathSegmentName(ref.Kind) { allErrs = append(allErrs, field.Invalid(fldPath.Child("kind"), ref.Kind, msg)) </ins> } <del> if ref.Namespace != "" { for _, msg := range apimachineryvalidation.ValidateNamespaceName(ref.Namespace, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("namespace"), ref.Namespace, msg)) } </del> <ins> } if ref.Name == "" { allErrs = append(allErrs, field.Required(fldPath.Child("name"), "")) } else { for _, msg := range pathvalidation.IsValidPathSegmentName(ref.Name) { allErrs = append(allErrs, field.Invalid(fldPath.Child("name"), ref.Name, msg)) } } // namespace is optional. if ref.Namespace != "" { for _, msg := range apimachineryvalidation.ValidateNamespaceName(ref.Namespace, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("namespace"), ref.Namespace, msg)) </ins> } } return allErrs

Discussion:
Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign
Change:
features.ValidatingAdmissionPolicy: { Default: true, PreRelease: featuregate.Alpha}}) if err != nil { <del> // FIXME: handle error. panic("Unexpected error") </del> <ins> t.Fatalf("Unable to add feature gate: %v", err) </ins> } err = featureGate.SetFromMap(map[string]bool{string(features.ValidatingAdmissionPolicy): true}) if err != nil { <del> // FIXME: handle error. panic("Unexpected error.") </del> <ins> t.Fatalf("Unable to store flag gate: %v", err) </ins> } plug, err := NewPlugin()

Discussion:
/sig testing
Just wanted to know to can I help in resolving the error handling ?
in /cc /sig api-machinery
/assign you are always welcome to help if you want to try to solve this and send a PR /triage accepted
/
can anyone suggest resources for this Issue as I am new to the testing of admission policy some guidance will surely help
I think both calls can simply be replaced with and a more helpful error message. Feel free to raise a PR, I'll take care of reviewing it.
Thanks for upfront help
Change:
command := exec.Command("umount", target) output, err := command.CombinedOutput() if err != nil { <ins> if err.Error() == errNoChildProcesses { if command.ProcessState.Success() { // We don't consider errNoChildProcesses an error if the process itself succeeded (see - k/k issue #103753). return nil } // Rewrite err with the actual exit error of the process. err = &exec.ExitError{ProcessState: command.ProcessState} } </ins> return fmt.Errorf("unmount failed: %vnUnmounting arguments: %snOutput: %s", err, target, string(output)) } return nil

Discussion:
While investigating some slowness in mounting/unmounting operations of PVs (in this case EFS volumes) for pods, we observed errors like these: fortunately it does recover quickly on Kubelet’s next retry: Looking through the Kubelet code I found out that the issue is not related to the umount calls themselves, but rather a race condition inside where we call umount. Because of the way golang’s function (called inside ) is implemented, it for the child process to finish after it is . Since there isn't any locking on the child process across those function calls, it's possible that the child process exits event before the Wait() call starts. In such case the wait call returns with a error (). This error is more likely to happen especially if the gap between the Start() and Wait() calls is more (which could for e,g happen if the goroutine had CPU cycles snatched away from it for some time in between those calls). A similar issue also exists in the . While this is a self-recovering issue (because of Kubelet retries), it does seem to increase the pod startup/cleanup latency upto a 1s. Open to suggestions for a fix. The simplest one occurring to me is to treat the error as a special one on which we don't actually return an error for the mount/unmount calls. /sig storage /sig scalability /assign
Another thing is when analyzing a distribution of such errors across different nodes, we observed a skew. The top 10% of the nodes were seeing more than 90% of these errors. And these are nodes that are running hotter (w.r.t the pod churn) compared to others: ! Given this, I'm wondering if those errors are higher on those nodes just because of statistical significance or other causes like more GC pauses happening on those nodes.
/triage accepted
^ I've opened this PR to fix the Mount/Unmount functions in the file. In general we might want to make a similar fix to other invocations of exec.Run() and exec.CombinedOutput() within our codebase. But that'll be a bigger change. Happy to open another issue for it.
Sorry for opening the PR against wrong repo, here's the right one -
Change:
"encoding/json" "fmt" "io" <ins> "io/ioutil" </ins> "math/rand" "reflect" "strings" "testing" ) <ins> func TestYAMLDecoderReadBytesLength(t *testing.T) { d := `--- stuff: 1 test-foo: 1 ` testCases := []struct { bufLen    int expectLen int expectErr error }{ {len(d), len(d), nil}, {len(d) + 10, len(d), nil}, {len(d) - 10, len(d) - 10, io.ErrShortBuffer}, } for i, testCase := range testCases { r := NewDocumentDecoder(ioutil.NopCloser(bytes.NewReader([]byte(d)))) b := make([]byte, testCase.bufLen) n, err := r.Read(b) if err != testCase.expectErr || n != testCase.expectLen { t.Fatalf("%d: unexpected body: %d / %v", i, n, err) } } } </ins> func TestSplitYAMLDocument(t *testing.T) { testCases := []struct { input  string

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: In a go program, using the YAML utility package "", the YAMLDecoder Read function always returns n=0 bytes, indicating that nothing was read. What you expected to happen: The number of bytes read should be returned as specified in the How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: minikube & AWS OS (e.g. from /etc/os-release): macOS 10.13.1 (17B1003) Kernel (e.g. ): Darwin 17.2.0 Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/cc
Change:
"k8s.io/klog" "k8s.io/kubernetes/pkg/kubelet/cm/cpumanager/state" "k8s.io/kubernetes/pkg/kubelet/cm/topologymanager" <ins> "k8s.io/kubernetes/pkg/kubelet/config" </ins> "k8s.io/kubernetes/pkg/kubelet/status" )

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: PR , it will remove "inactive containers" while reconciling. But the cpumanager started very beginning, it will get empty activePods at it first run. This make state file no sense. What you expected to happen: We should wait a moment or notification from podmanager before starting reconcile. Some log may be before remove "inactive containers". How to reproduce it (as minimally and precisely as possible): restart kubelet 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 node
In reconcileState : You mean the cpu assignments would be wiped for the first reconciliation ?
Yes, you can test it by restarting kubelet.
Do you see any of the following log:
I see this
/assign
Change:
} } else { node.Spec.ExternalID = kl.hostname <del> // If no cloud provider is defined - use the one detected by cadvisor info, err := kl.GetCachedMachineInfo() if err == nil { kl.updateCloudProviderFromMachineInfo(node, info) </del> <ins> if kl.autoDetectCloudProvider { // If no cloud provider is defined - use the one detected by cadvisor info, err := kl.GetCachedMachineInfo() if err == nil { kl.updateCloudProviderFromMachineInfo(node, info) } </ins> } } if err := kl.setNodeStatus(node); err != nil {

Discussion:
It appears that the kubelet will detect and use the cloud provider as detected by cadvisor thus overriding the cloud provider passed in at runtime: This will break our private cloud configuration where we do not use our cloud provider's load balancing and instead use our own load balancing tier. In my opinion, the cloud provider specified at kubelet runtime should be respected for the node. Am I reading this correctly? Any thoughts on how to handle this properly? Thank you!
If you specify any cloud provider through flags, it will be used by kubelet (see ). It's only when you don't specify any cloud provider that kubelet will detect the cloud provider from the machine info, as described by the comment.
that's exactly my situation, I want to run in our private cloud environment without any of the cloud integration. If I specify cloud-provider="" at runtime it will get overridden.
Ah I see. I guess specifying an empty string is the same as not specifying any cloud provider. This auto-detection feature was introduced by /cc the author and reviewer to see if this is an intended behavior:
Legitimate concern. I'm posting a fix. Do you consider this to be a regression or are you just getting started with k8s.
I am sorry, This was not the original intention. We can keep the auto detection with a flag, or make a flag to ask kubelet not to do it. Unless there is a way to see if the variable was assigned to that I missed. I can post a fix tomorrow if it won't exit by then.
Thank you. We're running on 1.2.4 and won't be running on 1.3 for a few months yet anyways and was just testing to look for future issues when I found this.
I assigned this issue to you since , and I can't assign this to anyway :-)
Thanks for testing our 1.3 release candidate, and reporting this regression to us. We are including the fix to 1.3.
Change:
<ins> package(default_visibility = ["//visibility:public"]) licenses(["notice"]) load( "@io_bazel_rules_go//go:def.bzl", "go_library", "go_test", ) go_library( name = "go_default_library", srcs = ["checks.go"], tags = ["automanaged"], ) go_test( name = "go_default_test", srcs = ["checks_test.go"], library = ":go_default_library", tags = ["automanaged"], deps = ["//vendor:k8s.io/apimachinery/pkg/util/wait"], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], ) </ins>

Discussion:
See: This code should make several attempts before ing. Alternatively, we could consider not listening for connections until this code has succeeded.
Feel free to correct me if I'm wrong on any of this since I've never looked at kubernetes code base before. The code for the and the both appear to make multiple attempts before returning an error which leads to a Fatal.
, I think we had waited for to start at . Do we need to wait more or make it configurable?
I would like to work on this if nobody else is.
No need to ask for permission! Just say here that you're working on it, that should be sufficient to prevent duplicate work. :)
Can I have a go at this?
I have a nearly completed solution for this already. Just working on testing/test cases. WIll hopefully sumbit a PR shortly.
Ok.
I wondered why we care about this. After all, kubelet restarts failing pods. For posterity, after talking with the reason is that the apiserver may fail so fast that the kubelet begins to back off on restarts of a failing pod. That backoff may be too aggressive. (Maybe it causes spurious alerts, or maybe it allows too much downtime.) So, let's fix the apiserver. That's fine, but clearly we're not the only user that might encounter this. You may be running a server you don't want to (or can't) modify, and you might wish you could tweak the kubelet's backoff heuristics for your pod. Alternately, maybe the kubelet could choose not to enter the backoff if apiserver exited with a different code. anything like this already in place?
That's a wonderful explanation that hadn't occurred to me. If there isn't a feature request for this already I'll work on something and reference this issue.
AFAIK, the backoff mechanism is there to protect kubelet from being overwhelmed by failed user containers. Trusting the containers with returning a specific exit code sounds like a big "no" to me. Making this configurable per pod might be ok, but it's still not good in general to allow aggressive restarts.
The referred PR () only fixes the issue for kube-apiserver. We still need a generic fix in genericapiserver (Ref ).
Change:
node.Status.Conditions = append(node.Status.Conditions, *nodeOODCondition) } <del> // NOTE(aaronlevy): NodeReady condition needs to be the last in the list of node conditions. // This is due to an issue with version skewed kubelet and master components. // ref: https://github.com/kubernetes/kubernetes/issues/16961 </del> var newNodeReadyCondition api.NodeCondition var oldNodeReadyConditionStatus api.ConditionStatus if containerRuntimeUp && networkConfigured && containerRuntimeVersionRequirementMet {

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 was looking into what tests were enabled for and found that the following tests: are running 1.18. From the output of the tests (): and What you expected to happen: tests to be running against the latest code for 1.19 How to reproduce it (as minimally and precisely as possible): It looks to be caused by the setting: 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 release /sig windows
Change:
run(ctx, initializers) }, OnStoppedLeading: func() { <del> klog.Fatalf("leaderelection lost") </del> <ins> klog.ErrorS(nil, "leaderelection lost") klog.FlushAndExit(klog.ExitFlushTimeout, 1) </ins> }, })

Discussion:
kube-controller-manager yields whole stack trace when it loses leaderelection. kube-controller-manager to only log and to exit (without logging 17K lines of stack trace that is not useful for anyone). kube-controller-manager yields around 17K lines of stack trace (omitted in the above example). No response <detailsv1.20.12 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
has Fatalf always triggered a stack dump of all goroutines?
/cc
Seems like does a dump of all goroutines Could we and then maybe? /cc in case you have thoughts about this
If I read the right, it only printed the current goroutine to stderr. Dumping everything seems to have been later. make sense to me.
Dumping of all goroutines was in
I have similar doubts. I want to fix it. /assign
kube-scheduler seems to have a similar issue (but a shorter stack trace)
When replacing (useful because it doesn't do structured logging, not just because of the stack trace problem), remember to use + the new . Updated migration instructions are pending in There's also - reverting the klog change might be a faster way to address this.
Change:
"k8s.io/kubernetes/pkg/kubelet/cm/cpuset" "k8s.io/kubernetes/pkg/kubelet/cm/topologymanager" "k8s.io/kubernetes/pkg/kubelet/cm/topologymanager/bitmask" <ins> "k8s.io/kubernetes/pkg/kubelet/metrics" </ins> ) const (

Discussion:
Add to enable observability of the cpumanager. This is required to but it's also useful in general. To the best of my knowledge, it's very hard to observe the behavior of cpumanager without peeking into the pod and/or use the podresources interface (kubelet = 1.24). But even for the latter, no well known components expose metrics consuming this information. I believe anyway kubelet some expose some basic metrics about cpumanager behaviour, while deferring more fine grained metrics to external components (NFD, node_exporter, is fine)
/sig node /assign
/triage accepted /priority important-soon (as this is important for graduation for CPU Manager to GA)
Change:
t.Fatalf("unexpected error while writing: %v", err) } } <ins> func TestWriteAgainAfterUnexpectedExit(t *testing.T) { testCases := []struct { name       string payload    map[string]FileProjection simulateFn func(targetDir string, payload map[string]FileProjection) error }{ { name: "process killed before creating user visible files", payload: map[string]FileProjection{ "foo": {Mode: 0644, Data: []byte("foo")}, "bar": {Mode: 0644, Data: []byte("bar")}, }, simulateFn: func(targetDir string, payload map[string]FileProjection) error { for filename := range payload { path := filepath.Join(targetDir, filename) if err := os.RemoveAll(path); err != nil { return err } } return nil }, }, } for _, tc := range testCases { tc := tc t.Run(tc.name, func(t *testing.T) { targetDir, err := utiltesting.MkTmpdir("atomic-write") if err != nil { t.Fatalf("unexpected error creating tmp dir: %v", err) } defer func() { err := os.RemoveAll(targetDir) if err != nil { t.Errorf("%v: unexpected error removing tmp dir: %v", tc.name, err) } }() writer := &AtomicWriter{targetDir: targetDir, logContext: "-test-"} err = writer.Write(tc.payload, nil) if err != nil { t.Fatalf("unexpected error writing payload: %v", err) } err = tc.simulateFn(targetDir, tc.payload) if err != nil { t.Fatalf("failed to simulate the unexpected exit: %v", err) } err = writer.Write(tc.payload, nil) if err != nil { t.Fatalf("unexpected error writing payload again: %v", err) } checkVolumeContents(targetDir, tc.name, tc.payload, t) }) } } </ins>

Discussion:
When kubelet is creating configmap volume for a pod, it finished writing dir and made symlink to . At the same time, the kubelet is restarted, unfortunately the configmap item symlink is not created. The restarted kubelet will try to configmap, . Kubelet should create absent symlink for configmap volume. can hack kubelet to help reproduce it: sleep some time before ` kubelet and start official kubelet will skip to create symlink for UserVisibleFiles No response_ <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 node
/sig storage This seems like an issue for sig storage. Can someone take a look and confirm?
Can you please add the version details as well?
/remove-sig node
/assign
Change:
"value": "{{ pillar.get('storage_backend', 'etcd3') }}" }, { "name": "TARGET_VERSION", <del> "value": "{{ pillar.get('etcd_version', '3.5.3') }}" </del> <ins> "value": "{{ pillar.get('etcd_version', '3.5.4') }}" </ins> }, { "name": "DO_NOT_MOVE_BINARIES",

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
ProbeRemove ) <ins> var ErrNoPluiginMatched = errors.New("no volume plugin matched") </ins> // VolumeOptions contains option information about a volume. type VolumeOptions struct { // The attributes below are required by volume.Provisioner

Discussion:
In the events , the PVC has been successfully resized, but a warning-level log is still printed. And by checking the logs of kube-controller-manager, can see the following output. Do not print events with warning level. To expand a a CSI PVC, and then use "kubectl describe pvc" to view its events. (I am using xsky CSI to expand pvc, but based on my understanding of Kubernetes code, this issue can occur with any CSI.) ! ! Based on Kubernetes v1.27.3, I some logs in the func located in . These logs printed all the plugins before expansion, and I noticed that was not among them. In my understanding, it is normal for CSI to be absent from the plugins here because CSI expansion is scheduled through external-resizer instead of kube-controller-manager. Therefore, there should not be any warning-level logs printed here either. v1.27.3 (In version 1.18, the issue can also be reproduced) <details</detailsLinux debian-hk 5.10.0-23-amd64 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux kind v0.20.0 <details</details<details</details
/sig storage
We can change the ExternalExpanding event from Warning to Info. are you interested in making this change?
/triage accepted
Yes, I will submit the pull request in the next few days.
Hi Have you submitted the PR? I have a bugfix branch tested on v1.29.1. I would like to cherry-pick it to master if this is not fixed yet or not started.
You can go do it. Thank you!
Change:
"flag" "fmt" "io/ioutil" <ins> "net/http" </ins> "os" "reflect" "sort"

Discussion:
The kubecfg -c option is used to pass a file pointer to a representation of a model object on disk (pod, replicationController, service) for use by the operation. It would be nice if I could do the following: Where kubecfg sees the http:// and does a network operation to fetch resource for me. This would let users who want to build tutorials on how to use kubernetes to avoid steps to manually download the files locally via curl and unzip, etc. and would also let scripters that use the kubecfg client to avoid needing write access on the terminal where they run kubecfg to perform basic actions.