jiebi/CodeConvo huggingface dataset:
Change:
kc.DockerExecHandler, kc.ResolverConfig, kc.CPUCFSQuota, <del> daemonEndpoints) </del> <ins> daemonEndpoints, kc.OOMAdjuster) </ins> if err != nil { return nil, nil, err

Discussion:
The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. 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 See PR for docs at 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
~This would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.
Change:
} } else { klog.V(2).Infof("azureDisk - attach disk(%s) succeeded", diskName) <del> // Invalidate the cache right after updating as.cloud.vmCache.Delete(vmName) </del> } return err }

Discussion:
What happened: Azure Disks get randomly mounted in a way that makes them unusable, returning for every disk I/O operation. Affected Pods remain in until someone manually recreates them. What you expected to happen: Azure Disks are consistently usable by Pods inside which they are mounted. How to reproduce it: Create the following StatefulSet. Adjust the replicas and delete the associated Pods () until the problem occurs (i.e. some Pod ends up in ). <details</summary</details</brDefault StorageClass (as created by ACS-Engine): <details</summary</details</brAnything else we need to know?: Nodes were updated from 1.10.4 to 1.10.10, then from 1.10.10 to without a reboot. According to written by the issue is fixed, but I can still observe it quite often. Ref Azure/acs-engine Environment: Kubernetes version: v1.10.10 + Cloud provider or hardware configuration: Azure (westeurope) OS: Ubuntu 16.04.4 LTS Kernel: 4.13.0-1018-azure Install tools: ACS-Engine Others: /kind bug /sig storage /sig azure
In my current test environment: (pod uid is -f23b-11e8-bf38-) on the node Notice the mismatch between the disk referenced by lun0 () and the actual mount (). on the node
After deleting the failing Pod and waiting for its successful recreation: (pod uid is now -f247-11e8-bf38-) on the node This time disks are matching (). on the node
/assign
Change:
# Windows path it'll use it instead of the default unzipper. # See: https://github.com/containerd/containerd/issues/1896 Add-MachineEnvironmentPath -Path $PIGZ_ROOT <del> # Add process exclusion for Windows Defender to boost performance. </del> <ins> # Add process exclusion for Windows Defender to boost performance. </ins> Add-MpPreference -ExclusionProcess "$PIGZ_ROOTunpigz.exe" Log-Output "Installed Pigz $PIGZ_VERSION" } else {

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 --The default fluent-bit configuration for GCE Windows nodes produces unparsed JSON logs and does not forward container logs. Container log output is produced. fluent-bit on a given windows image. a GCE Windows e2e cluster and view the stackdriver output for pods. Kubernetes version (use ): 1.20+ Cloud provider or hardware configuration: GKE/GCE OS (e.g: ): Windows Kernel (e.g. ): Any version Install tools: fluent-bit 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 windows
Change:
// SystemDaemonsetStartup is how long to wait for all system daemonsets to be ready. SystemDaemonsetStartup time.Duration <ins> // NodeNotReady is how long to wait for a node to be not ready. NodeNotReady time.Duration </ins> } // NewTimeoutContext returns a TimeoutContext with all values set either to

Discussion:
We need to explore how DRA interacts with One likely outcome is that the DRA helper code watches for nodes with the special label and helps DRA drivers clean up. /sig node
/assign
/triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29 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
/triage accepted
Here's a test that was written for volumes:
Thank you. I’ve found it last week. Unfortunately kind image doesn’t have ssh, so stopping kubelet is not possible the way this test does. I’ve found another solution.
I was able to simulate non-graceful node shutdown by running . It turned out that after adding tent, all node pods are deleted by the GC controller and the resource claim controller successfully deallocated the resource. So, it looks like a non-graceful shutdown is handled correctly and no code changes are required. However, the fact that can potentially be called without calling should be explained in the DRA KEP, so that DRA plugin authors will be aware of this. I'll add an explanation of handling non-graceful node shoutdown to the and add a correspondent e2e test case to the DRA e2e test suite.
KEP update PR: E2E PR:
Change:
gce := &GCECloud{ service:                  service, <ins> serviceAlpha:             serviceAlpha, </ins> serviceBeta:              serviceBeta, containerService:         containerService, cloudkmsService:          cloudkmsService,

Discussion:
Causes failures in:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig network /area platform/gce platform/gke

/kind bug /sig storage
/assign
It also fails on debian GKE. However, they all pass on debian and GCI GCE. Error msg is mounting timed out. This leads me to suspect that there is some difference in networking for GKE vs GCE.
I do strongly suspect there is some networking issue on GKE. Many other tests are also failing with "connection timed out" errors. 1.7 GKE tests are looking healthy, so it seems like something is broken on master. /sig network
Fixed by /close
Change:
"errors" "fmt" "os" <ins> "path" </ins> "path/filepath" "k8s.io/klog"

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: dir crated in would not be automatically removed. What you expected to happen: when a pod delete the, the dir would be removed How to reproduce it (as minimally and precisely as possible): create a pod using csi raw block volume and delete it Anything else we need to know?: ! pod using pv--6195-49a0-b262- actually has been deleted and the volume has been unmounted, but the dir still exists. ! {pv}/data still exists Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /assign
I am afraid that the fix won't work for all volume plugins. I randomly checked where some volume plugins symlinks a device: iscsi: aws: So, iSCSI would be cleaned with this PR, but just as a coincidence, not as deliberate design. And AWS would still leave orphaned . I am not convinced that this we don't have a plugin that does not use subdirectories. I think a better approach is necessary. Perhaps of every plugin should clean up everything that created?
thanks for your advice, I would try to find a better approach
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
is being reverted because it broke CSI block volume cleanup
/assign
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 rotten is this still an issue?
I am adding CSI directories cleanup in
This should be fixed by /close
Closing this issue. <detailsIn response to : This should be fixed by /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:
} // ServiceBackendPort is the service port being referenced. <ins> // +structType=atomic </ins> message ServiceBackendPort { // name is the name of the port on the Service. // This is a mutually exclusive setting with "Number".

Discussion:
I created an Ingress resource with a port number manually, and then tried to use an Operator with server-side apply to update the resource from a port number to a port name. This failed with the error message "cannot set both port name & port number". I expected the port number to be cleared as the operator would take over the ownership of the ServiceBackendPort. To simulate the behavior in the operator in a most simple example I use : ingress- ingress- This will print: It seems to me that the merge type for the struct ServiceBackendPort should to be set to "atomic" , so that the Operator updating the port should take over the whole struct, and two applications shouldn't update single fields in it. Red Hat OpenShift on AWS OS version of the client: NAME="Fedora Linux" VERSION="40 (Workstation Edition)" Linux 6.9.6-200.fc40.x8664 SMP PREEMPTDYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
/sig network
So, on one hand you made a problem when you used two different owners to manage one aspect of the object. On the other hand, I think you're right that it SHOULD work. Probably. is not a super common tag, and ingress way predates it, so no surprise it isn't used. I ACK the issue and reproduced it. I ran update-codegen and built a KinD cluster from HEAD.
this may be something you want to look at for DRA API - I didn't even realize this was a thing until today :)
The API uses for , which is very similar. So using it for LGTM. SSA will auto-migrate existing resources using once the change is released.
/triage accepted
"this" being "add "? I can see where this might be useful, probably on all one-of structs and perhaps on those containing a discriminator because otherwise SSA leaves fields set which should be cleared when some other owner takes over. Is this important enough to put into I don't see a big need for SSA in general and even less for SSA with different owners at the moment - this will change once we do more with status.
No, not urgent. This is the first time it has come up in my awareness ever. But now that I know about it, I could see how it applies to dra.

Thank to everyone involved here to resolve this! This will make things simpler in the Keycloak operator once it is released.
Thanks for filing a good (and easy to fix :) bug. Easy repro means we can jump on it.
Change:
"context" "fmt" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
Tests in are failing because they are faulty. A container can't read from a file if it has selinux permission denied for it. More context - /sig node /sig storage
something we can look into.
Also,
The tests expect that SELinux blocks a pod with label "s0:c2,c3" reading a file created by a pod with label "s0:c0,c1". Since the tests runs on GCI, where SELinux is not available, nothing blocks the read and the tests can't ever pass. The tests should check that the node has SELinux in Enforcing mode and skip the tests otherwise. Somewhere around these parts, where we write/read a file in the first "s0:c0,c1" pod: Is there an easy way how to test that in /proc or /sys in a non-privileged busybox container?
There are two problems. First one is obviously - the test can't run on non-selinux systems, but second one is - it is also broken on selinux enabled systems as per
To check whether SELinux is in enforced mode, one can check that read returns "1". I've implemented that in a particular case that relies on selinux being enforced: To check whether SELinux is enabled (I guess this is a prerequisite for all the test cases in ), one can use from (which of course should be run in a proper context). In case a check for a particular container is needed, the presence of directory should be enough. Having said that, I'm not sure how to properly wrap the above check(s) into (or , or whatever).
Change:
quotaPeriod:      tunedQuotaPeriod, expected:         &ResourceConfig{CpuShares: &guaranteedShares, CpuQuota: &cpuNoLimit, CpuPeriod: &tunedQuotaPeriod, Memory: &guaranteedMemory}, }, <ins> "burstable-partial-limits-with-init-containers": { pod: &v1.Pod{ Spec: v1.PodSpec{ Containers: []v1.Container{ { Resources: getResourceRequirements(getResourceList("100m", "100m"), getResourceList("100m", "100Mi")), }, { Resources: getResourceRequirements(getResourceList("100m", "100m"), getResourceList("", "")), }, }, InitContainers: []v1.Container{ { Resources: getResourceRequirements(getResourceList("100m", "100m"), getResourceList("100m", "100Mi")), }, { Resources: getResourceRequirements(getResourceList("100m", "100m"), getResourceList("", "")), }, }, }, }, enforceCPULimits: true, quotaPeriod:      tunedQuotaPeriod, expected:         &ResourceConfig{CpuShares: &burstablePartialShares}, }, </ins> } for testName, testCase := range testCases {

Discussion:
I noticed ResourceConfigForPod isn't checking here: The methods called by ( and ) do check , but it looks like and can be true for burstable pods even when some of the initContainers do not declare cpu/memory limits. I'm not sure what the implications of setting these values are if an initContainer has no cpu or memory limit: /sig node /assign
After reading the code, I prefer that this is a bug according to . would you confirm? /assign I opened .
/triage accepted
Change:
import ( "fmt" "net/http" <ins> "reflect" </ins> "sync" "sync/atomic" "time"

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
This is pretty much the same failure, that are happening in "gce-enormous" suite and we currently debugging them with The main reason of those failures is that we are terminating all watchers for a particular resource type from time to time, and some of them are actually causing a snowball effect. After more looking into it, my hypothesis is that our machinery for aggregating watchers in apiserver sometimes is just to slow. In particular, I some log in my local branch and what I'm observing is that in etcd_watcher, we are: accumulating objects in incoming channel but also accumulating objects in outgoing channel, and the accumulation there is usually higher [I will send a PR to put those logs into master - they seem to be pretty useful for debugging such issues.] So my current hypothesis is that dispatching watch events to watchers is what is too slow. We will continue debugging.
The logs that I seem to confirm my hypothesis - outgoing channel is generally more full then the incoming channel in etcd_watcher: vs I'm working on the PR that should at least improve the situation.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Please apply the label to this issue if it does not need to be fixed before we launch 1.4. Otherwise please advise on how to proceed with respect to 1.4.
This was a regression - I fixed it by reverting an offending PR: This seems to be fixed now.
I have 33 pods in my container (1 is substantive, the other 32 just run on log files). I get this all the time now. I'm running 1.5.4.
- to be honest, I don't undertsand what your wrote. what is "container" in "33 pods in my container"? Also, if you believe there is a bug somewhere, please open a new issue instead of adding comment to more than half-year-old one.
Change:
. "github.com/onsi/gomega" ) <del> var _ = framework.KubeDescribe("Kubelet Cgroup Manager", func() { </del> <ins> var _ = framework.KubeDescribe("Kubelet Cgroup Manager [Skip]", func() { </ins> f := framework.NewDefaultFramework("kubelet-cgroup-manager") Describe("QOS containers", func() { Context("On enabling QOS cgroup hierarchy", func() {

Discussion:
In node-e2e-test on Containervm image, the containers of the pods created by Kubernetes are subcontainers of docker-daemon/docker/. It means that the runtime resource usage (docker-daemon) is not correct, because all pods are included. This problem maybe due to container misconfiguration in node-e2e-test.
The kubelet on debian-based containervm image is misconfigured. Will fix it shortly.
Change:
ServiceCheck{Service: "docker"}, ServiceCheck{Service: "kubelet"}, PortOpenCheck{port: 10250}, <ins> HttpProxyCheck{Proto: "https", Host: cfg.MasterAddresses[0], Port: int(cfg.APIPort)}, HttpProxyCheck{Proto: "http", Host: cfg.MasterAddresses[0], Port: int(cfg.DiscoveryPort)}, </ins> DirAvailableCheck{Path: "/etc/kubernetes"}, DirAvailableCheck{Path: "/var/lib/kubelet"}, InPathCheck{executable: "ebtables", mandatory: true},

Discussion:
Environment: VMware CentOS Linux release 7.2.1511 (Core) kernel: 3.10.0-327.36.1.el7.x8664 Installed packages: kubeadm.x8664 1.5.0-0.alpha.0.1534.gcf7301f kubectl.x8664 1.4.0-0 kubelet.x8664 1.4.0-0 kubernetes-cni.x8664 0.3.0.1-0. docker-engine.x8664 1.11.2- docker-engine- 1.12.1- What happened: kubeadm init hangs indefintely after: kubeadm init <master/tokensgenerated token: "." <master/pkicreated keys and certificates in "/etc/kubernetes/pki" <util/kubeconfigcreated "" <util/kubeconfigcreated "" <master/apiclientcreated API client configuration <master/apiclientcreated API client, waiting for the control plane to become readykubeadm init What you expected to happen: Master node initialize Anything else do we need to know: Only the kubeadm and kublet processes are running. When I do docker ps no containers are running. If i type docker images the only image that has been downloaded are: I've also tried: kubeadm init --api-advertise-addresses but with the same outcome (followed the clean-up at ) Im behind a firewall so I'm using proxy settings for docker. I have confirmed I can reach images on docker hub and google cloud registry
will download the required binaries viz etcd. When you are behind firewall kubeadm will hang/wait forever to download the binaries. I dont know whether it is addressed correctly in kubeadm implementation. I am also facing the same issue and waiting for the resolution.
Thx, I suspected it to be some firewall issue. Do you know if there's a way to add httpsproxy & httpproxy settings to kubeadm?
Kubeadm doesn't seem to pick proxy environment variables. I am looking at recompiling with proxy support may work. But I dont know how to do that. Waiting for updates about proxy
This issue same as Lets join there. The solution mentioned there may work.

You can try kubeadm with patch applied from PR : It works at least in my environment behind restrictive proxy.
thanks, I will look into it
Change:
return "unknown" } <ins> // lazyScope implements String() string and it will // lazily get Scope from request info type lazyScope struct { req *http.Request } func (lazy *lazyScope) String() string { if lazy.req != nil { ctx := lazy.req.Context() requestInfo, ok := apirequest.RequestInfoFrom(ctx) if ok { return metrics.CleanScope(requestInfo) } } return "unknown" } </ins>

Discussion:
One of the use-cases for APIServer tracing would be to try and debug SLO-violating requests served by the API Server. Right now, it adds just some basic attributes: For API Server , SLO-related metrics have the following labels: "verb", "dryrun", "group", "version", "resource", "subresource", "scope", "component", "code" We should add those labels to at least one of the spans created by API Server requests. It isn't a graduation requirement for , but would make the feature more helpful.
/sig instrumentation
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
We might be able to do something using RequestInfo, similar to how the dropped request metric is recorded: