jiebi/CodeConvo huggingface dataset:
Code change:
It("processes in different containers of the same pod should be able to see each other", func() { // TODO(yguo0905): Change this test to run unless the runtime is // Docker and its version is <1.13. <del> By("Check whether shared PID namespace is enabled.") isEnabled, err := isSharedPIDNamespaceEnabled() </del> <ins> By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() </ins> framework.ExpectNoError(err) if !isEnabled { <del> framework.Skipf("Skipped because shared PID namespace is not enabled.") </del> <ins> framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") </ins> } By("Create a pod with two containers.")

Related discussion:
text: if I run systemd and journald, I can actually retrieve and use this information.
If the intension is to force all containers inside of a POD to run with the same PID Namespace? I think this is a mistake since it eliminates another really cool use case. I would love to be able to run two containers inside of a pod, and INIT container with escallated privileges and a locked down container, with no privileges. I want to make sure the locked down container can not see the processes of the privileged container. An example of this, might be a container that loads a kernel module that is needed by the locked down container. Another use case would be a buildah container. The INIT container mounts up a COW file system onto a directory on a location that the locked down container can write, The locked down container writes out the data for his image, when the container completes, the INIT container commits the data to the repo. I believe allowing different containers inside of a POD to run with different security and isolated PIDs should not be removed.
none of the things you've mentioned are removed by this change, save using docker to hide other processes in the pod, and I'm not sure why that's a requirement. Is anyone currently using the "privileged sidecar" pattern you describe or is it hypothetical? It just occurred to me that an interesting compromise here might be to only enable shared pid for multi-container pods. This would enable pod semantics for PID when it would make a difference while drop-in docker monoliths keep the PID 1 behavior they're expecting in docker. I'd have to double check, but I'm pretty sure that behavior could be implemented entirely in the dockershim with no API or CRI changes.
Hypothetical, but I am pushing it for a solution for problems I hear from users fairly frequently, where then need big privileges at start and stop of the pod, but not for the time is is available to the network.
ok, thanks. ftr, I think we should continue to support this pattern as well, and I don't think a shared PID namespace prohibits it. I will bring up this issue at Tuesday's sig node meetup if you'd like to join us. Does the config I mentioned in fix the issue with systemd?
Code change:
It("processes in different containers of the same pod should be able to see each other", func() { // TODO(yguo0905): Change this test to run unless the runtime is // Docker and its version is <1.13. <del> By("Check whether shared PID namespace is enabled.") isEnabled, err := isSharedPIDNamespaceEnabled() </del> <ins> By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() </ins> framework.ExpectNoError(err) if !isEnabled { <del> framework.Skipf("Skipped because shared PID namespace is not enabled.") </del> <ins> framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") </ins> } By("Create a pod with two containers.")

Related discussion:
text: Copying from a comment made elsewhere:
Update from SIG Node Meetup: Everyone wants to support these use cases, but we're not yet sure the requirements we want to support medium to long term. is going to sync up with and then we'll figure out what we want to support in a future release. For 1.8 the current plan is to leave docker shared pid namespace enabled by default. Cluster administrators can disable it per-node with the --docker-disable-shared-pid flag. I'll see about whether we should add something back to the release notes.
This seems somewhat backwards. Wouldn't it make more sense to go back to supporting systemd use cases by default NOW (by making the shared PID namespace behavior optional or something) until a final decision is reached and can be advertised to current users?
absolutely ! thank you very much
I think that is the best solution is to make the PID Namespace sharing optional.
- optional at what scope - cluster, node, pod. let's sync up before next sig-node and we can revisit if need be before 1.8 goes out. The main question right now is if pid namespace sharing is opt-in or opt-out. We need to weigh pro/cons of both.
I would expect it at the POD, since pods would have different requirements, not sure why you would want to have this at the cluster or node level.
yes it works :)
awesome, thanks! I'd like to better understand the requirements of people objecting to this change ( I think there's a bit of confusion about what has changed, so let's start with some facts: This container image runs on Kubernetes without changes to the image, but it requires (non-obvious) pod configuration. is nothing inherently incompatible between a shared pid namespace and a process manager like systemd. systemd and other init systems work with pid != 1, but may require special invocation. in this issue is specific to Kubernetes. That is, this container image wouldn't work with vanilla docker PID namespace sharing, either. change does not affect securityContext I can think of a few things that are objectionable about the change, but let's state them as requirements. For example, are these requirements for anyone? Kubernetes must run all containers published on docker hub with no additional pod configuration Kubernetes must run all systemd containers, regardless of how they are built, with zero additional pod configuration.
Code change:
It("processes in different containers of the same pod should be able to see each other", func() { // TODO(yguo0905): Change this test to run unless the runtime is // Docker and its version is <1.13. <del> By("Check whether shared PID namespace is enabled.") isEnabled, err := isSharedPIDNamespaceEnabled() </del> <ins> By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() </ins> framework.ExpectNoError(err) if !isEnabled { <del> framework.Skipf("Skipped because shared PID namespace is not enabled.") </del> <ins> framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") </ins> } By("Create a pod with two containers.")

Related discussion:
text: Kubernetes must run this specific container image with zero additional configuration Kubernetes must officially support isolated PID namespaces between containers in a single pod across all runtimes (docker, rkt, hyperv, etc). Configuration changes are ok, but the flag to systemd cannot be used because the documentation says its not useful. I want to use systemd as intended. Rather than having Kubernetes work around this container image, should we patch the Dockerfile to make it compatible with even the native docker shared-pid, unrelated to Kubernetes?
Configuration changes are ok, but the --system flag to systemd cannot be used because the documentation says its not useful. I want to use systemd as intended. We can ask the systemd guys why they recommend never using the --system flag, but I would guess one of the reasons is that processes showing up that were not created in the ancestry of systemd, could cause confusion. I would also guess that running more then one container with systemd --system would not be supported. Kubernetes must officially support isolated PID namespaces between containers in a single pod. This is required so that you can run different containers with different security constraints in the same pod at the same time. Your last comment makes the seem like it is the default, when actually it is the exception. almost no containers run with shared-pid normally. I guess in a side car container, it makes sense to support this scenario, but forcing this as the ONLY way to run containers is limiting.
This is the part I don't understand. Why? What does PID visibility have to do with security constraints? What am I missing? nor do they run with a shared network namespace, but we impose that on docker containers because that's the pod model.
An update from the last SIG Node: we'll disable this by default in 1.8 and revisit for 1.9 I'll use to track that.
if I have a privileged container process in the same pid namespace as a pid in a non priv container, then the container process in the non priv can attack the priv process. Having them in separate pid namespaces gives you better security. Bottom line, you have a potential change where containers that expect to be run as PID 1, whether legitimately or not, could break when you make this change. Kubernetes in my opinion should make it easy to opt out of this behavior.
Code change:
It("processes in different containers of the same pod should be able to see each other", func() { // TODO(yguo0905): Change this test to run unless the runtime is // Docker and its version is <1.13. <del> By("Check whether shared PID namespace is enabled.") isEnabled, err := isSharedPIDNamespaceEnabled() </del> <ins> By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() </ins> framework.ExpectNoError(err) if !isEnabled { <del> framework.Skipf("Skipped because shared PID namespace is not enabled.") </del> <ins> framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") </ins> } By("Create a pod with two containers.")

Related discussion:
text: /priority critical-urgent
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Update: is pending review and should be to the v1.8 Milestone to resolve this issue.
Code change:
q.ToDec().d.Dec.Sub(q.d.Dec, y.AsDec()) } <ins> // Mul multiplies the provided y to the current value. // It will return false if the result is inexact. Otherwise, it will return true. func (q *Quantity) Mul(y int64) bool { q.s = "" if q.d.Dec == nil && q.i.Mul(y) { return true } return q.ToDec().d.Dec.Mul(q.d.Dec, inf.NewDec(y, inf.Scale(0))).UnscaledBig().IsInt64() } </ins> // Cmp returns 0 if the quantity is equal to y, -1 if the quantity is less than y, or 1 if the // quantity is greater than y. func (q *Quantity) Cmp(y Quantity) int {

Related discussion:
text: I'd like to add a multiplication method for the resource.Quantity. Currently, the resource package provides helper methods to calculate Quantity, such as and : Batch workloads often replicate the same PodTemplate, and controllers calculate the resources needed for all containers. In that case, It is inconvenient to call the function as many times as podTemplate, so I would like to create a helper function for multiplication.
/cc /sig api-machinary /wg batch
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /cc /sig api-machinary /wg batch </details
/sig api-machinery /wg batch
Do you have an example of usage for these utilities? Just curious?
/triage accepted
Sorry for the late response. Taking k-sigs/kueue as an example, I assumed the below: It helps the controllers for batch workloads such as k-sigs/kueue, k-sigs/jobset, kubeflow/mpi-operator, and kubeflow/training-operator. I'm thinking of implementing this function once the code freeze term is finished.
/assign
Hi, may i take this up?
I took this one, and working on this now.
Code change:
package transport <ins> // this is just to make the "unused" linter rule happy var _ = isCacheKeyComparable[tlsCacheKey] </ins> // assert at compile time that tlsCacheKey is comparable in a way that will never panic at runtime. <del> var _ = isComparable[tlsCacheKey] </del> <ins> // // Golang 1.20 introduced an exception to type constraints that allows comparable, but not // necessarily strictly comparable type arguments to satisfy the `comparable` type constraint, // thus allowing interfaces to fulfil the `comparable` constraint. // However, by definition, "A comparison of two interface values with identical // dynamic types causes a run-time panic if that type is not comparable". // // We want to make sure that comparing two `tlsCacheKey` elements won't cause a // runtime panic. In order to do that, we'll force the `tlsCacheKey` to be strictly // comparable, thus making it impossible for it to contain interfaces. // To assert strict comparability, we'll use another definition: "Type // parameters are comparable if they are strictly comparable". // Below, we first construct a type parameter from the `tlsCacheKey` type so that // we can then push this type parameter to a comparable check, thus checking these // are strictly comparable. // // Original suggestion from https://github.com/golang/go/issues/56548#issuecomment-1317673963 func isCacheKeyComparable[K tlsCacheKey]() { _ = isComparable[K] } </ins> func isComparable[T comparable]() {}

Related discussion:
text: The code freeze is starting in a week, and we want to ensure that each PR has a chance to be merged on time.
We are past the code freeze stage. Moving this to the next release. /milestone v1.31
Hello This issue has not been updated for a long time, so I'd like to check what's the status. The , and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time. As the issue is tagged for , is it still planned for this release?
Hello, This issue/PR hasn't been updated in a while, so I just wanted to check the status. If there's anything we can do, please let us know. Reminder: Code freeze starts (about 1.5 weeks from now). Please make sure the PR has both and labels before the code freeze.
/milestone v1.32
/assign
Code change:
} // tryUnmount calls plain "umount" and waits for unmountTimeout for it to finish. <del> func tryUnmount(mounter *Mounter, path string, unmountTimeout time.Duration) error { klog.V(4).Infof("Unmounting %s", path) </del> <ins> func tryUnmount(target string, withSafeNotMountedBehavior bool, unmountTimeout time.Duration) error { klog.V(4).Infof("Unmounting %s", target) </ins> ctx, cancel := context.WithTimeout(context.Background(), unmountTimeout) defer cancel() <del> cmd := exec.CommandContext(ctx, "umount", path) out, cmderr := cmd.CombinedOutput() </del> <ins> command := exec.CommandContext(ctx, "umount", target) output, err := command.CombinedOutput() </ins> // CombinedOutput() does not return DeadlineExceeded, make sure it's // propagated on timeout.

Related discussion:
text: A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </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 storage
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.
Code change:
} // LocalEndpoint empty implementation <del> func LocalEndpoint(path, file string) string { return "" </del> <ins> func LocalEndpoint(path, file string) (string, error) { return "", fmt.Errorf("LocalEndpoints are unsupported in this build") </ins> } // GetBootTime empty implementation

Related discussion:
text: What happened: I replaced the kubelet on one of my 1.14 nodes with a build from master, and now I'm getting this error starting up. Test passes since 5/31/2019 commit have been failing on testgrid. If you look at the logs, the Windows nodes are not coming up. What you expected to happen: No errors starting up kubelet How to reproduce it (as minimally and precisely as possible): Build master, then try to run the kubelet on Windows Anything else we need to know?: /sig windows Environment: Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..529 Install tools: aks-engine
cc /priority critical-urgent
/milestone v1.15 Release team - it looks like a recent PR broke windows nodes. We will need a fix here for 1.15
Ok, so the problem here is a little more complicated and we're actually seeing a bug that is actually in the code for quite some time, just that we never used that particular code path. But first: TL;DR: Quick fix is to start the kubelet on Windows with: --feature-gates="KubeletPodResources=false" Now, as to why this is happening: PR [1] was merged 3 days ago and it graduates KubeletPodResources feature as Beta. That means kubelet will enable it by default.With the introduction of the above feature, this branch of code is entered when starting kubelet [2]. We can see a call to the function: defined here [3].While innocent enough, gets the necessary npipe by calling: . is defined here [4] for Windows . The problem is actually that url.URL can't handle Windows style paths [5] and will replace "" with "%5C" as it's to be expected. The paths are transformed along the way from the default "/var/lib/kubelet" to "varlibkubelet" by defined here [6]. More specifically in the use of to create a path. It's inputs are unix style but returns the path Windows style as it's to be expected.The solution is to replace the usage of url.URL in with some alternative package or just implement it.
Code change:
} // LocalEndpoint empty implementation <del> func LocalEndpoint(path, file string) string { return "" </del> <ins> func LocalEndpoint(path, file string) (string, error) { return "", fmt.Errorf("LocalEndpoints are unsupported in this build") </ins> } // GetBootTime empty implementation

Related discussion:
text: [1] [2] [3] [4] [5] [6]
Thanks for the analysis! I was a bit concerned around the fact that this started showing up around my commit: but the root cause here is indeed, as you said, the graduation of feature to Beta and the way the invalid escape sequences are being introduced.
GCE tests failing too /cc
I'm trying a quick to see if anything else is broken. There are other functions in that same file doing that substitution already so it may make sense to use that as a workaround until a better solution is available.
Still working on it - looks like the path to create the directories is also busted. With still getting
Code change:
return tmpDir, plug } <ins> func getNodeExpandablePlugin(t *testing.T, isBlockDevice bool) (string, volume.NodeExpandableVolumePlugin) { tmpDir, err := utiltesting.MkTmpdir("localVolumeTest") if err != nil { t.Fatalf("can't make a temp dir: %v", err) } plugMgr := volume.VolumePluginMgr{} var pathToFSType map[string]hostutil.FileType if isBlockDevice { pathToFSType = map[string]hostutil.FileType{ tmpDir: hostutil.FileTypeBlockDev, } } else { pathToFSType = map[string]hostutil.FileType{ tmpDir: hostutil.FileTypeDirectory, } } plugMgr.InitPlugins(ProbeVolumePlugins(), nil /* prober */, volumetest.NewFakeKubeletVolumeHostWithMounterFSType(t, tmpDir, nil, nil, pathToFSType)) plug, err := plugMgr.FindNodeExpandablePluginByName(localVolumePluginName) if err != nil { os.RemoveAll(tmpDir) t.Fatalf("Can't find the plugin by name") } if plug.GetPluginName() != localVolumePluginName { t.Errorf("Wrong name: %s", plug.GetPluginName()) } return tmpDir, plug } </ins> func getPersistentPlugin(t *testing.T) (string, volume.PersistentVolumePlugin) { tmpDir, err := utiltesting.MkTmpdir("localVolumeTest") if err != nil {

Related discussion:
text: There are use cases where users want to expand the local volume (may be managed by LVM or something similar), but even though they can edit underlying PV (and expand the underlying device) - the reported size in pvc.Status keeps reporting older value because in-tree local volumes are non-expandable. We could make this easier for users by - implementing interface for local volumes. This would allow following steps for local volume expansion: /admin edits the pvc - requesting new size. expands the underlying device. edits the PV and sets new size. will expand the filesystem and update This would at least get the user from impossible territory to possible. cc /sig storage
/triage accepted
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
Hi & any news on this issue ? The related PR seems stalled.
merged. So this is fixed now.
Oh right ! I didn't looked close enough and thought it was only for directory based volumes. Thank you.