jiebi/CodeConvo huggingface dataset:
Code change:
} // create target_dir before call to NodePublish <del> if err := os.MkdirAll(dir, 0750); err != nil && !corruptedDir { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", dir, err)) </del> <ins> parentDir := filepath.Dir(dir) if err := os.MkdirAll(parentDir, 0750); err != nil { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", parentDir, err)) </ins> } <del> klog.V(4).Info(log("created target path successfully [%s]", dir)) </del> <ins> klog.V(4).Info(log("created target path successfully [%s]", parentDir)) </ins> nodePublishSecrets = map[string]string{} if secretRef != nil {

Related discussion:
text: For the mount point checking here before calling NodePublishVolume, I am wondering it is just for performance optimization, or it has other purposes. Have concern about some drivers might depend on this check if they are not implemented with idenpotency.
Those drivers would be operating in violation of the specification. I'd prefer that we don't penalize already conforming and yet-to-be written drivers in order to accommodate these existing drivers—if they even exist.
More fallout in last night's testing: I introduced a bug into my driver that caused it to panic during ("Writing that data to a set of files in the mounted filesystem"). My handler function is set up to unmount a successfully mounted volume via if it doesn't complete steps 2 and 3 above, in order to deal with this issue's principal complaint. My driver container would crash due to this panic. The kubelet would call on my driver twice, it would crash twice, but the pod still started running. I'm not yet sure whether or not the filesystem got unmounted successfully via the on the first call, but somehow the pod started despite my handler function never completing successfully. I'm going to try to get some more debugging time on this later today to see if I can figure out what the kubelet was doing there.
Studying my code more, I see that my function only unmounted the mounted directory when the containing handler function was returning an error. When unwinding due to a panic, the named return value of type I was inspecting was still nil. Revising the criteria in that function covers both failure reasons (returning an and unwinding due to a panic). Regardless, this further underscores the problem: If a driver makes it as far as mounting a filesystem at the target directory, but fails afterward—including the process crashing and never responding positively to the RPC—the mounting pod will start. That's likely to then cause the pod to fail, for lack of the files it expected to find mounted.
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
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Code change:
} // create target_dir before call to NodePublish <del> if err := os.MkdirAll(dir, 0750); err != nil && !corruptedDir { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", dir, err)) </del> <ins> parentDir := filepath.Dir(dir) if err := os.MkdirAll(parentDir, 0750); err != nil { return errors.New(log("mounter.SetUpAt failed to create dir %#v:  %v", parentDir, err)) </ins> } <del> klog.V(4).Info(log("created target path successfully [%s]", dir)) </del> <ins> klog.V(4).Info(log("created target path successfully [%s]", parentDir)) </ins> nodePublishSecrets = map[string]string{} if secretRef != nil {

Related discussion:
text: 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
/remove-lifecycle stale
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
/remove-lifecycle stale
Code change:
util-linux  socat  curl  <ins> git  </ins> && DEBIAN_FRONTEND=noninteractive apt-get autoremove -y  && DEBIAN_FRONTEND=noninteractive apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Related discussion:
text: I'm running Kubernetes under Docker (following guide). I tried to set up an RC that would run a registry:2 container and attach a gitRepo volume with the SSL certs I want to use. When I run it though, I get this error: If k8s supports git repositories as volumes though, it feels like the executable should be included in the container.
k8s supports git repositories as volumes but it's an optional feature that not everyone wants, so it would not be appropriate to require/include the git executable. This is similar to how k8s supports nfs volumes, but we don't require you to run the kubelet on an os with nfs kernel support, because not everyone wants it.
Hmm. Okay, that makes sense. Would it be feasible to create tags for those containers that have git?
I think I misunderstood the request. I think it's actually reasonable to add git to hyperkube, since afaict, it's only used for single node docker. The Dockerfile is , feel free to send a pr.
Code change:
import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Related discussion:
text: The e2e test should be relaxed. It currently checks 3 different aspects of the volume mount flag: with do not receive mounts from outside their own mount namespace, nor do mount namespaces outside the container receive mounts created within the container. with receive new mounts from the host OS, the container runtime, and other containers with , but no mount namespaces outside the container receive mounts created within the container. with receive new mounts identical to containers with , but additionally any mounts made by these containers are: propagated to the container runtime where they can be propagated to other containers (related to 2) also propagated to the Host OS The first 3 aspects, up to and including 3.i, are critical for container operation and should still be ensured by an e2e test. This last check, 3.ii., is the part that I believe is overly strict. The current e2e test is too opinionated on the underlying node OS configuration. The requirement of propagation to the host OS precludes administrators or solution providers from modifying the Kubernetes installation to hide these Kubernetes-specific mountpoints, which can be for a variety of reasons: While access to container-specific mounts in Kubernetes (like secrets) today are protected by filesystem permissions, the fact that the locations are visible to unprivileged users via the 'mount' command can provide information which could be used in conjunction with other vulnerabilities to decipher secrets or other protected container mount contents. Locking access to even listing the mountpoints behind the ability to enter the mount namespace (which in turn requires and ) removes one level of potential access to container-specific mounts. These container overlay mounts, secret and configmap mounts, and namespace mounts are all internal implementation details around the way the Kubernetes and the Container Runtime allocate resources to containers. For normal day-to-day operation, there is no need for these special-use mounts to be visible in the host OS's top-level 'mount' or 'findmnt' output. After much investigation and conversation on both the sig-node and sig-storage mailing lists, as well as within Red Hat's OpenShift communities, we have yet to turn up a use case that relies on this container-to-host propagation. In fact, it may be seen as an anti-pattern and run contrary to the container-native way of doing things. Relying on a host OS to interact with a container-owned mountpoint seems suspect.
Code change:
import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Related discussion:
text: Today systemd's CPU usage is adversely affected by a large number of mountpoints, especially versions released prior to December 2020. This feature of systemd, which scans all /proc/1/mount to invoke udev events for every change suffers from two issues. The first was an inefficiency in systemd’s processing logic. This was fixed in December 2020, and this fix reportedly reduced the systemd mount-scanning-related overhead by 30-50%. The second is a lack of granularity in the events the kernel sends to systemd about mountpoint changes, which necessitates a full rescan of all mountpoints even on a minor change or single mountpoint addition. The kernel change to remedy this seems unlikely to move forward in the near term. (See for more details) For example, a fairly small OpenShift deployment today (which does not yet have the systemd December 2020 fix) has upwards of 400 mountpoints on every node owned by Kubelet, the Container Runtime, and infrastructure containers like OVN or CSI operators. Hiding the container mountpoints reduces the steady-state systemd CPU utilization from ~10% to ~0% on every worker node. On a more heavily loaded system, with 1000’s of container mountpoints, systemd’s usage will cap out at 100% of a single CPU core. Even with the 30-50% reduction in systemd usage expected from the December 2020 fix, having systemd take up as much as 50-70% of a single CPU in the worst-case scenario is a lot of unnecessary overhead. Administrators of other OSes with other host OS services that monitor or process mountpoints indiscriminately would be able to hide these container-specific mountpoints from the OS at large, at their option. With this requirement relaxed, it would be possible to run multiple instances of Kubernetes on a single host without the various mountpoints interfering with one another. There may be other inter-instance difficulties besides the mount namespace, but this does move in that direction without resorting to more complicated solutions like trying to run Kubernetes inside of containers.
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 .
Code change:
import ( "fmt" <ins> "strings" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig architecture storage /area conformance
I have a proof-of-concept of the relaxed test as well as some more and an OpenShift-based proof-of-concept of an actual implementation with the container mounts in their own namespace
/sig node
There's still a number of other issues, no? Is this a real motivation / use-case? There are other difficulties. Most of the difficulties with running Kubernetes inside containers are just the difficulties in sharing a kernel / host OS, which aren't related to this at all. The security and performance angles seem relevant, in any case.
Update: I mistakenly referred to this as a "conformance test" - Turns out it is not in fact a conformance test; just an e2e test :) Edited the original post to be more correct in this respect.
/remove-area conformance /area test
Fair point. I this (intentionally vague) section since some conversation on the sig-node mailing list with folks working on KIND suggested this may align with their goals in some way I'm not entirely clear on.
A good next step on this issue is to open a PR to the related e2e tests that documents why the tests are not good candidates for future inclusion in conformance. Is that something you can assist with ?
I have a branch that relaxes the test so it works in the current environment and a separated mount namespace environment... Can you explain a bit more what you mean about documenting this? Where would that kind of documentation go?
Code change:
} func createVolumeConfigMap(config *localTestConfig) { <del> mountConfig := struct { HostDir string `json:"hostDir"` }{ HostDir: path.Join(hostBase, discoveryDir), </del> <ins> // MountConfig and ProvisionerConfiguration from // https://github.com/kubernetes-incubator/external-storage/blob/master/local-volume/provisioner/pkg/common/common.go type MountConfig struct { // The hostpath directory HostDir string `json:"hostDir" yaml:"hostDir"` </ins> } <del> data, err := json.Marshal(&mountConfig) </del> <ins> type ProvisionerConfiguration struct { // StorageClassConfig defines configuration of Provisioner's storage classes StorageClassConfig map[string]MountConfig `json:"storageClassMap" yaml:"storageClassMap"` } var provisionerConfig ProvisionerConfiguration provisionerConfig.StorageClassConfig = map[string]MountConfig{ config.scName: { HostDir: path.Join(hostBase, discoveryDir), }, } data, err := yaml.Marshal(&provisionerConfig.StorageClassConfig) </ins> Expect(err).NotTo(HaveOccurred()) configMap := v1.ConfigMap{

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The local-volume bootstrapper/provisioner configuration format changed in kubernetes-incubator/external-storage, and its related e2e tests will fail when the provisioner & bootstrapper images are updated to v2.0.0. What you expected to happen: I'd expect the e2e tests to continue to work properly with the new version of the provisioner and boostrapper. How to reproduce it (as minimally and precisely as possible): Update local-volume provisioner and boostrapper images to v2.0.0, and then the provisioner e2e test will fail.
/sig storage
/assign
Code change:
return } // Node that isn't present according to the cloud provider shouldn't have its address updated <del> exists, err := ensureNodeExistsByProviderIDOrInstanceID(instances, node) </del> <ins> exists, err := ensureNodeExistsByProviderID(instances, node) </ins> if err != nil { // Continue to update node address when not sure the node is not exists glog.Errorf("%v", err)

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The change here removes exiternal id, but the call to instance id was not made used at all, it will always return false. At this time no node was able to register What you expected to happen: ProviderId was used in check How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment:
similar to are you using --cloud-provider in your controller manager? are you also setting it on your kubelet?
I'm using acs-engine to deploy the cluster. Config is as following: I've proposed a fix. PTAL
/sig cluster-lifecycle
Code change:
touch /tmp/ready touch /tmp/liveness <del> while true; do </del> <ins> while true; do </ins> echo "hello" sleep 10 done

Related discussion:
text: Tests in are using image for gRPC probe tests: should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe We should use image for these tests as it is much smaller size. /sig node /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue KEP:
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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 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
Hi can I work on this issue? I'm new to Kubernetes and want to contribute!
Should I change to in this file?
Yes.
Code change:
touch /tmp/ready touch /tmp/liveness <del> while true; do </del> <ins> while true; do </ins> echo "hello" sleep 10 done

Related discussion:
text: Also pass proper parameters to agnhost to enable gRPC endpoint, change ports, and run tests to ensure that this worked.
Thanks for your reply! Will let you know if I have more questions as I work
/assign
/assign
Code change:
} if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

Related discussion:
text: When running the scheduler at or greater, the processed component config may be logged as a single line with newline characters inserted, like so: config should always be readable and formatted to an easily copied/parsed format, like: Not sure how often this happens, need to try reproducing ref and 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 scheduling
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
The problem has been reproduced. Here are the steps : Steps to Reproduce: kubeadm a pod network runtime, ( I used calico in my case). to reporter's kube-scheduler config yaml, here is another one. apiVersion: clientConnection: acceptContentTypes: "" burst: 100 contentType: application/vnd.kubernetes.protobuf kubeconfig: qps: 50 enableContentionProfiling: true enableProfiling: true healthzBindAddress: "" kind: KubeSchedulerConfiguration leaderElection: leaderElect: true leaseDuration: 15s renewDeadline: 10s resourceLock: leases resourceName: kube-scheduler resourceNamespace: kube-system retryPeriod: 2s metricsBindAddress: "" parallelism: 16 percentageOfNodesoScore: 0 podInitialBackoffSeconds: 1 podMaxBackoffSeconds: 10 profiles: pluginConfig: args: apiVersion: kind: NodeAffinityArgs name: NodeAffinity args: run the kube-scheduler command with an unassigned ip address that your control-plane can bind to: -scheduler --config scheduler- --bind-address "172.18.56.64" -v 5 Here, v can be anything greater than 3. the config file will have n characters in it, whereas it should have been formatted correctly. W1012 19:21:54. ] No authorization-kubeconfig provided, so SubjectAccessReview of authorization tokens won't work.
Code change:
} if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

Related discussion:
text: I1012 19:21:54. ] "Using component config" config="apiVersion: nclientConnection:n acceptContentTypes: ""n burst: 100n contentType: application/vnd.kubernetes.protobufn kubeconfig: n qps: 50nenableContentionProfiling: truenenableProfiling: truenhealthzBindAddress: ""nkind: KubeSchedulerConfigurationnleaderElection:n leaderElect: truen leaseDuration: 15sn renewDeadline: 10sn resourceLock: leasesn resourceName: kube-schedulern resourceNamespace: kube-systemn retryPeriod: 2snmetricsBindAddress: ""nparallelism: 16npercentageOfNodesToScore: 0npodInitialBackoffSeconds: 1npodMaxBackoffSeconds: 10nprofiles:n- pluginConfig:n - args:n apiVersion: n kind: DefaultPreemptionArgsn minCandidateNodesAbsolute: 100n minCandidateNodesPercentage: 10n name: DefaultPreemptionn - args:n apiVersion: n hardPodAffinityWeight: 1n kind: InterPodAffinityArgsn name: InterPodAffinityn - args:n apiVersion: n kind: NodeAffinityArgsn name: NodeAffinityn - args:n apiVersion: n kind: NodeResourcesBalancedAllocationArgsn resources:n - name: cpun weight: 1n - name: memoryn weight: 1n name: NodeResourcesBalancedAllocationn - args:n apiVersion: n kind: NodeResourcesFitArgsn scoringStrategy:n resources:n - name: cpun weight: 1n - name: memoryn weight: 1n type: LeastAllocatedn name: NodeResourcesFitn - args:n apiVersion: n defaultingType: Systemn kind: PodTopologySpreadArgsn name: PodTopologySpreadn - args:n apiVersion: n bindTimeoutSeconds: 600n kind: VolumeBindingArgsn name: VolumeBindingn plugins:n bind:n enabled:n - name: DefaultBindern weight: 0n filter:n enabled:n - name: NodeUnschedulablen weight: 0n - name: NodeNamen weight: 0n - name: TaintTolerationn weight: 0n
Code change:
} if klog.V(2).Enabled() { <del> klog.InfoS("Using component config", "config", buf.String()) </del> <ins> klog.Info("Using component config", "n-------------------------Configuration File Contents Start Here---------------------- n", buf.String(), "n------------------------------------Configuration File Contents End Here---------------------------------n") </ins> } if len(fileName) > 0 {

Related discussion:
text: - name: NodeAffinityn weight: 0n - name: NodePortsn weight: 0n - name: NodeResourcesFitn weight: 0n - name: VolumeRestrictionsn weight: 0n - name: EBSLimitsn weight: 0n - name: GCEPDLimitsn weight: 0n - name: NodeVolumeLimitsn weight: 0n - name: AzureDiskLimitsn weight: 0n - name: VolumeBindingn weight: 0n - name: VolumeZonen weight: 0n - name: PodTopologySpreadn weight: 0n - name: InterPodAffinityn weight: 0n permit: {}n postBind: {}n postFilter:n enabled:n - name: DefaultPreemptionn weight: 0n preBind:n enabled:n - name: VolumeBindingn weight: 0n preFilter:n enabled:n - name: NodeResourcesFitn weight: 0n - name: NodePortsn weight: 0n - name: VolumeRestrictionsn weight: 0n - name: PodTopologySpreadn weight: 0n - name: InterPodAffinityn weight: 0n - name: VolumeBindingn weight: 0n - name: NodeAffinityn weight: 0n preScore:n enabled:n - name: InterPodAffinityn weight: 0n - name: PodTopologySpreadn weight: 0n - name: TaintTolerationn weight: 0n - name: NodeAffinityn weight: 0n queueSort:n enabled:n - name: PrioritySortn weight: 0n reserve:n enabled:n - name: VolumeBindingn weight: 0n score:n enabled:n - name: NodeResourcesBalancedAllocationn weight: 1n - name: ImageLocalityn weight: 1n - name: InterPodAffinityn weight: 1n - name: NodeResourcesFitn weight: 1n - name: NodeAffinityn weight: 1n - name: PodTopologySpreadn weight: 2n - name: TaintTolerationn weight: 1n schedulerName: default-schedulern" Will be trying to write a unit-test for the same.