jiebi/CodeConvo huggingface dataset:
Change:
<ins> #!/bin/bash # Copyright 2016 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. echo "Removing empty directories from etcd..." cleanup_empty_dirs () { if [[ $(${ETCDCTL} ls $1) ]]; then for SUBDIR in $(${ETCDCTL} ls -p $1 | grep "/$") do cleanup_empty_dirs ${SUBDIR} done else echo "Removing empty key $1 ..." ${ETCDCTL} rmdir $1 fi } while true do echo "Starting cleanup..." cleanup_empty_dirs "/registry" echo "Done with cleanup." sleep ${SLEEP_SECOND} done </ins>  No newline at end of file

Discussion:
I came upon a cluster that had had the namespace code thoroughly exercised. No namespaces currently existed, but many had been created and deleted in the past. Its etcd had lots of empty directories under each resource that had held items when those namespaces were alive (secrets, serviceaccounts, pods...). Do we need to be doing something to clean these empty directories up? It seems like this etcd was consuming a lot of memory.
or might know the answer to this question.
Right. We should delete them. It might get tricky for concurrent cases like A checks if dir is empty, B creates, then A deletes it. What does it look like currently in creating and deleting namespace?
How much memory does a directory entry take? Does it really sound possible to run out of memory while snapshotting on account of too many empty directories?
-- have you guys encountered this? I think you run with more namespaces than we do. But maybe yours are mostly populated?
Yes, we've seen it. c.f.
Approximate memory use we saw from empty dirs:
cc
The patch we debated carrying is here: Our hope was to just wait to etcd v3 where this would not be a problem.
can you link to your clean-up script here?
I needed another PR to run the pod automatically on master.
Change:
for _, tc := range testCases { t.Run(tc.testName, func(t *testing.T) { <del> recycleSlices(tc.startingSlices) </del> <ins> startingSlices := tc.startingSlices recycleSlices(startingSlices) unorderedSlices := [][]*discovery.EndpointSlice{startingSlices.toCreate, startingSlices.toUpdate, startingSlices.toDelete} for _, actual := range unorderedSlices { sort.Slice(actual, func(i, j int) bool { return actual[i].Name < actual[j].Name }) } </ins> <del> expectEqualSlices(t, tc.startingSlices.toCreate, tc.expectedSlices.toCreate) expectEqualSlices(t, tc.startingSlices.toUpdate, tc.expectedSlices.toUpdate) expectEqualSlices(t, tc.startingSlices.toDelete, tc.expectedSlices.toDelete) </del> <ins> expectEqualSlices(t, startingSlices.toCreate, tc.expectedSlices.toCreate) expectEqualSlices(t, startingSlices.toUpdate, tc.expectedSlices.toUpdate) expectEqualSlices(t, startingSlices.toDelete, tc.expectedSlices.toDelete) </ins> }) } }

Discussion:
seen in the PR updating to go1.15, but this unit test should not be flaky /assign
was the flaky run
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
can reproduce locally with:
looks like toCreateByAddrType is a map which doesn't have a defined iteration order, so the address family order of toUpdate is not well-defined
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
t.Errorf("error creating strategy for %s: %v", k, err) } errs := s.Validate(nil, v.groups) <del> if v.pass && len(errs) > 0 { </del> <ins> if v.expectedError == "" && len(errs) > 0 { </ins> t.Errorf("unexpected errors for %s: %v", k, errs) } <del> if !v.pass && len(errs) == 0 { t.Errorf("expected no errors for %s but got: %v", k, errs) </del> <ins> if v.expectedError != "" && len(errs) == 0 { t.Errorf("expected errors for %s but got: %v", k, errs) } if v.expectedError != "" && len(errs) > 0 && !strings.Contains(errs[0].Error(), v.expectedError) { t.Errorf("expected error for %s: %v, but got: %v", k, v.expectedError, errs[0]) </ins> } } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help
Change:
EnableServiceLinks: tc.enableServiceLinks, }, } <del> podIP := "1.2.3.4" podIPs := []string{"1.2.3.4,fd00::6"} </del> <ins> podIP := "" if len(tc.podIPs) > 0 { podIP = tc.podIPs[0] } </ins> if tc.staticPod { testPod.Annotations[kubetypes.ConfigSourceAnnotationKey] = "file" } <del> result, err := kl.makeEnvironmentVariables(testPod, tc.container, podIP, podIPs) </del> <ins> result, err := kl.makeEnvironmentVariables(testPod, tc.container, podIP, tc.podIPs) </ins> select { case e := <-fakeRecorder.Events: assert.Equal(t, tc.expectedEvent, e)

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 --In a dual-stack cluster with IPv4 as default family (first kubelet IP), a container is created with a env var set to . When the container is running, properly contains the IPv4 But at runtime, this env var (used in container args) is expanded to the pod IPv6 instead of the IPv4. When using , it should always return the value actually exposed as and not something else. Kubernetes version:Cloud provider or hardware configuration: Bare metal cluster OS (e.g: ): Ubuntu 20.04 Kernel (e.g. ): Linux 5.8.0-59-generic 66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x8664 x8664 x86_64 GNU/Linux Network plugin and version (if this is a network-related bug): cilium 1.10 Others: CRI-O 1.21 + crun.
Note: I have a configuration that matches the ones that had IP ordering issue before was fixed. So it may be related.
/sig network
Just a guess, but I wonder if it may be caused by
That's it. The fix from properly sort IP when computing the Pod status, but the sorted IPs are then replaced by computed IPs as this log shows.
/triage accepted Thanks for the detailed report
/assign
Change:
} wait.Wait() } <del> if controller.Status.Replicas != activePods { controller.Status.Replicas = activePods </del> <ins> if controller.Status.Replicas != numActivePods { controller.Status.Replicas = numActivePods </ins> _, err = rm.kubeClient.ReplicationControllers(controller.Namespace).Update(&controller) if err != nil { return err

Discussion:
I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil
Change:
"fmt" "time" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/api/meta" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" </ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apiserver/pkg/endpoints/handlers/fieldmanager/internal" openapiproto "k8s.io/kube-openapi/pkg/util/proto" "sigs.k8s.io/structured-merge-diff/fieldpath" "sigs.k8s.io/structured-merge-diff/merge" <ins> "sigs.k8s.io/yaml" </ins> ) // FieldManager updates the managed fields and merge applied

Discussion:
What happened: When sending a request to the server side apply endpoint (), if the apiVersion provided in the object is different from the apiVersion in the url, it returns a 500 error, like: What you expected to happen: The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error. Anything else we need to know?: The check should probably be done somewhere near this . The issue, though, is that the patch is given as a byte array, and needs to be deserialized into an object to access the apiVersion field. How to reproduce it (as minimally and precisely as possible): With a kube-apiserver built from head, running with :
/kind bug /sig api-machinery /wg apply /priority important-longterm /assign
Change:
func NewFramework(fns []RegisterPluginFunc, opts ...runtime.Option) (framework.Framework, error) { registry := runtime.Registry{} plugins := &schedulerapi.Plugins{} <del> var pluginConfigs []schedulerapi.PluginConfig </del> for _, f := range fns { <del> f(&registry, plugins, pluginConfigs) </del> <ins> f(&registry, plugins) </ins> } <del> return runtime.NewFramework(registry, plugins, pluginConfigs, opts...) </del> <ins> return runtime.NewFramework(registry, plugins, nil, opts...) </ins> } // RegisterPluginFunc is a function signature used in method RegisterFilterPlugin() // to register a Filter Plugin to a given registry. <del> type RegisterPluginFunc func(reg *runtime.Registry, plugins *schedulerapi.Plugins, pluginConfigs []schedulerapi.PluginConfig) </del> <ins> type RegisterPluginFunc func(reg *runtime.Registry, plugins *schedulerapi.Plugins) </ins> // RegisterQueueSortPlugin returns a function to register a QueueSort Plugin to a given registry. func RegisterQueueSortPlugin(pluginName string, pluginNewFunc runtime.PluginFactory) RegisterPluginFunc {

Discussion:
/sig scheduling /triage accepted The method in only modifies the slice of PluginConfig internally. Instead, the method should return the appended slice so that callers can override the original. For example, here:
/assign
ref:
Hey are you still working on this, if not I'd like to try it out!
Hi I'm still working on this. Thanks for your interest about this issue.
Change:
klog.ErrorS(err, "getNodeAnyway function failed") return false, nil, "" } <ins> podCopy := pod.DeepCopy() </ins> cpuAvailable := node.Status.Allocatable.Cpu().MilliValue() memAvailable := node.Status.Allocatable.Memory().Value() <del> cpuRequests := resource.GetResourceRequest(pod, v1.ResourceCPU) memRequests := resource.GetResourceRequest(pod, v1.ResourceMemory) </del> <ins> cpuRequests := resource.GetResourceRequest(podCopy, v1.ResourceCPU) memRequests := resource.GetResourceRequest(podCopy, v1.ResourceMemory) </ins> if cpuRequests > cpuAvailable || memRequests > memAvailable { <del> klog.V(3).InfoS("Resize is not feasible as request exceeds allocatable node resources", "pod", pod.Name) return false, nil, v1.PodResizeStatusInfeasible </del> <ins> klog.V(3).InfoS("Resize is not feasible as request exceeds allocatable node resources", "pod", podCopy.Name) return false, podCopy, v1.PodResizeStatusInfeasible </ins> } // Treat the existing pod needing resize as a new pod with desired resources seeking admit.

Discussion:
mutates the pod object in place (vs creating a copy first). That's illegal and can cause data races or potentially panics (the panic is unlikely here but I can't rule it out). This line should be: This should be fixed because we might serialize the object in the middle of this from somewhere else and if the object changes midway the protobuf object we create may not be valid, leading to panics in kubelets with this gate turned on. /sig node /priority critical-urgent /kind bug /assign No mutation of pod objects from within methods (in fact no mutation of should occur in most loops). N/A 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
ACK. I'll fix it shortly.
is similar. is my try for both data races that we found.
One small , thanks.
Please review
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
Change:
} func containerIsNetworked(containerName string) bool { <del> return false </del> <ins> return containerName == PodInfraContainerName </ins> } // Returns nil as both Seccomp and AppArmor security options are not valid on Windows

Discussion:
Kubernetes version: master branch. Environment: OSX. What happened: cc/
I just took as an example. When running on OSX, always returns . However, on Linux, the actual calling path is , which will return when is . When get , will not run, which will call methods TearDownPod. And this is why on OSX calls to testing.MockNetworkPlugin.TearDownPod are missing.
Thanks. Could you file a PR to fix this?
Change:
} return strings.Contains(output, "This is a test file.") }, 1*time.Minute, 1*time.Second).Should(gomega.BeTrue()) }) }) })

Discussion:
Cluster api provides a framework to run the e2e tests which uses the conformance image: The gmsa tests use bash to install the webhook: The test will fail when run in the conformance image because of the bash: we should install the component another way run this e2e conformance image with /sig windows fyi <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
Conformance image:
Hi does the "work e2e" test case pass? Deploying GMSA webhook is the same for both "work e2e" and this test case.
no, they both fail due to bash not being present in the conformance image. The gmsa tests themselves pass if I run locally
/sig testing
Change:
} } <ins> func TestHasMountRefs(t *testing.T) { testCases := map[string]struct { mountPath string mountRefs []string expected  bool }{ "plugin mounts only": { mountPath: "/var/lib/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", mountRefs: []string{ "/home/somewhere/var/lib/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", "/var/lib/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", "/mnt/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", "/mnt/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", }, expected: false, }, "extra local mount": { mountPath: "/var/lib/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", mountRefs: []string{ "/home/somewhere/var/lib/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", "/local/data/kubernetes.io/some-plugin/mounts/volume-XXXX", "/mnt/kubelet/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", "/mnt/plugins/kubernetes.io/some-plugin/mounts/volume-XXXX", }, expected: true, }, } for name, test := range testCases { actual := HasMountRefs(test.mountPath, test.mountRefs) if actual != test.expected { t.Errorf("for %s expected %v but got %v", name, test.expected, actual) } } } </ins> func TestMountOptionFromSpec(t *testing.T) { scenarios := map[string]struct { volume            *volume.Spec

Discussion:
See This happens on ubuntu images on GKE when the node ephemeral storage is on local SSD. /sig storage /assign
/triage accepted
Change:
ForceUserspaceProxy bool SyncPeriod          time.Duration nodeRef             *api.ObjectReference // Reference to this node. <ins> MasqueradeAll       bool </ins> } // NewProxyServer creates a new ProxyServer object with default parameters

Discussion:
Related to . As a safety mesure, it could be very useful to actually include a flag to proxy to MASQUERADE everything (acting very close to a userspace proxy). I think it's not very hard to do and a very good way to diagnose or even fallback in case of problem (I'm thinking about vxlan cases). Something like "--snat-clients" or "--snat-pods" could be appropriate.
/cc
Looking at the current code: It looks like we SNAT almost everything already now? Would adding a set-mark rule (behind the flag of course) at line 548 be sufficient? Deprecated Public IPs, Loadbalancer IPs, and NodePorts all appear to be marked for SNAT already (also endpoint loopback traffic).
I think that is the flag, yeah. , Benjamin Elder wrote:
Ok, I'll push out a PR for that in a moment. I should be able to take care of that and the cleanup flag (PR out but needs some more work) today. On Aug 20, 2015 2:12 PM, "Tim Hockin" wrote:
Change:
"k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/validation/field" celconfig "k8s.io/apiserver/pkg/apis/cel" "k8s.io/apiserver/pkg/features"

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
// PodKiller handles requests for killing pods type PodKiller interface { // KillPod receives pod speficier representing the pod to kill <del> KillPod(pair *kubecontainer.PodPair) </del> <ins> KillPod(podPair *kubecontainer.PodPair) </ins> // PerformPodKillingWork performs the actual pod killing work via calling CRI // It returns after its Close() func is called and all outstanding pod killing requests are served PerformPodKillingWork()

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: Right after calling , returns false even the pod is not killed yet. What you expected to happen: In kubelet, after is complete, the pod should be pending termination or be killed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Related to 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:
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 /assign