jiebi/CodeConvo huggingface dataset:
Code change:
return utilfile.FileExists(pathname) } <ins> func (mounter *Mounter) EvalHostSymlinks(pathname string) (string, error) { return filepath.EvalSymlinks(pathname) } </ins> // formatAndMount uses unix utils to format and mount the given disk func (mounter *SafeFormatAndMount) formatAndMount(source string, target string, fstype string, options []string) error { readOnly := false

Related discussion:
text: /kind bug Using , if a block device is symlinked to the discovery directory e.g. , then MapVolume will fail with since the containerized kubelet cannot see the path on host. is mounted by containerized kubelet, so if before we try to map the device we set devicePath to the evaluation of symlink and end up with a devicePath of , containerized kubelet will see the device and successfully map the device. Are there any issues with this solution? This is on Kubernetes 1.10
/sig storage
ah yes containerized kubelet has many issues when dealing with symlinks. Check out Mounter.GetMode(), it calls a nsenter EvalSymlinks which should be able to do what you need. But actually, one thing to consider, is do you need to do the losetup on the host, or does inside the container work?
Yes it appears to work from inside the container, on the host I run which disappears after I delete the pod using the device. My understanding of running losetup in MapVolume is not that great but I suppose that as long as that /dev/loop0 is created we are fine. Thanks for the quick response, I'll create a PR using that function and tag you
Does it create it on the host or in the containerized kubelet? What happens when containerized kubelet is restarted? The purpose of losetup is to do "refcounting" on the block device to prevent possible naming collisions when devices are attached/detached under unhealthy conditions. Ie, if a device showed up as /dev/sdb and you gave that to a pod, and then for some reason it become unhealthy and disappeared (while the pod is still running), another device (maybe even another volume type) could get attached to the node and reuse /dev/sdb. Now the pod has access to a device it's not supposed to. With filesystem volumes, the refcounting is done with mount points, but for block device, loopback is the equivalent.
It is created on the host (and also visible in the container), and stays around through restart. I understand now, thank you.
Actually after I restart it becomes /vdb instead of /dev/vdb in the losetup output, idk what that is about.
Code change:
return utilfile.FileExists(pathname) } <ins> func (mounter *Mounter) EvalHostSymlinks(pathname string) (string, error) { return filepath.EvalSymlinks(pathname) } </ins> // formatAndMount uses unix utils to format and mount the given disk func (mounter *SafeFormatAndMount) formatAndMount(source string, target string, fstype string, options []string) error { readOnly := false

Related discussion:
text: There is no such thing as /vdb and /dev/vdb is still intact of course. Seems inconsequential since it is disappearing after all pods using the device are deleted, i.e. it's still serving as a refcounter
Code change:
`, inhibitDelayMax.Seconds()) logindOverridePath := filepath.Join(logindConfigDirectory, kubeletLogindConf) <del> if err := ioutil.WriteFile(logindOverridePath, []byte(inhibitOverride), 0755); err != nil { </del> <ins> if err := ioutil.WriteFile(logindOverridePath, []byte(inhibitOverride), 0644); err != nil { </ins> return fmt.Errorf("failed writing logind shutdown inhibit override file %v: %v", logindOverridePath, err) }

Related discussion:
text: <!-- 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: ! What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.20.1 Cloud provider or hardware configuration: OS (e.g: ): 7 Kernel (e.g. ): Linux zsm-test-2 3.10.0-1160.11.1.el7.x8664 SMP Fri Dec 18 16:34:56 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node
/triage accepted /priority backlog
Code change:
kubectl get services "${kube_flags[@]}" kubectl get services "service-${version}-test" "${kube_flags[@]}" kubectl delete service frontend "${kube_flags[@]}" <ins> servicesbefore="$(kubectl get services  -o template -t "{{ len .items }}" "${kube_flags[@]}")" kubectl create -f examples/guestbook/frontend-service.json "${kube_flags[@]}" kubectl create -f examples/guestbook/redis-slave-service.json "${kube_flags[@]}" kubectl delete services frontend redisslave # delete multiple services at once servicesafter="$(kubectl get services  -o template -t "{{ len .items }}" "${kube_flags[@]}")" [ "$((${servicesafter} - ${servicesbefore}))" -eq 0 ] </ins> kube::log::status "Testing kubectl(${version}:replicationcontrollers)" kubectl get replicationcontrollers "${kube_flags[@]}"

Related discussion:
text: Currently, it could not delete multiple pods at once, need to delete them one by one, it's very inconvenient if I have tons of pods to delete. Unlike docker, docker can multiple stop/rm containers/images at once.
This is possible using label selectors as of , which is better if you have tons of pods.
I agree that using label selector is better to delete all of pods under the label. But to delete multile pods at once is still usable: I just want to delete 1/2 pods under the label, label selector will not work selector could not span over other selectors or pods Another reason is docker rm/stop x y z works, I will wonder why kubectl cannot. This is not urgent, but I hope it can be implemented.
I agree. Thanks for the suggestion.
Would this be a suitable task for someone new to k8s development? If so, I'd be willing to take a look at this, if someone could provide a couple of hints where to start.
Further to my last message, I have a functional work in progress I would like to share, if anyone is interested?
PRs are welcome. See
Yes, this is a reasonable place to start. Since its in the client, you won't get much orientation to the core server code, but it will be a good place to orient to the client side API. There us also prior art that you can model off of. The kubectl create ... command already supports multiple resources. A good command to adapter would be the 'label' command. You can find it in Many thanks in advance! Brendan On Feb 19, 2015 8:21 AM, "Eric Tune" wrote:
Code change:
} func getFitPredicateFunctions(names sets.String, args PluginFactoryArgs) (map[string]predicates.FitPredicate, error) { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> fitPredicates := map[string]predicates.FitPredicate{} for _, name := range names.List() {

Related discussion:
text: What would you like to be : Currently Mutex lock is acquired in for accessing different maps. Some functions only read map entry: We can utilize RWMutex where the above function acquires read lock. Why is this needed: For concurrent calls to IsFitPredicateRegistered / IsPriorityFunctionRegistered, read lock would lower contention.
/sig scheduling
functions getFitPredicateFunctions, getPriorityFunctionConfigs, ListRegisteredFitPredicates, ListRegisteredPriorityFunctions and GetAlgorithmProvider can also use read lock.
I happened to raise earlier today. Anyone can finish resting ones.
Good to know,
Thanks for raising this ! My PR covered and . Feel free to raise another PR to cover others.
Once is merged, I will send my PR thanks
it's merged now.
Code change:
func (b *Builder) ResourceTypeAndNameArgs(args ...string) *Builder { switch len(args) { case 2: <del> b.name = args[1] </del> <ins> b.names = append(b.names, args[1]) </ins> b.ResourceTypes(SplitResourceArgument(args[0])...) case 0: default:

Related discussion:
text: Currently, it could not delete multiple pods at once, need to delete them one by one, it's very inconvenient if I have tons of pods to delete. Unlike docker, docker can multiple stop/rm containers/images at once.
This is possible using label selectors as of , which is better if you have tons of pods.
I agree that using label selector is better to delete all of pods under the label. But to delete multile pods at once is still usable: I just want to delete 1/2 pods under the label, label selector will not work selector could not span over other selectors or pods Another reason is docker rm/stop x y z works, I will wonder why kubectl cannot. This is not urgent, but I hope it can be implemented.
I agree. Thanks for the suggestion.
Would this be a suitable task for someone new to k8s development? If so, I'd be willing to take a look at this, if someone could provide a couple of hints where to start.
Further to my last message, I have a functional work in progress I would like to share, if anyone is interested?
PRs are welcome. See
Yes, this is a reasonable place to start. Since its in the client, you won't get much orientation to the core server code, but it will be a good place to orient to the client side API. There us also prior art that you can model off of. The kubectl create ... command already supports multiple resources. A good command to adapter would be the 'label' command. You can find it in Many thanks in advance! Brendan On Feb 19, 2015 8:21 AM, "Eric Tune" wrote:
Code change:
pod := makeLocalPodFunc(config, testVol, nodeName) pod, err := config.client.CoreV1().Pods(config.ns).Create(pod) Expect(err).NotTo(HaveOccurred()) <del> err = framework.WaitForPodRunningInNamespace(config.client, pod) Expect(err).To(HaveOccurred()) checkPodEvents(config, pod.Name, ep) </del> <ins> err = framework.WaitForPodNameUnschedulableInNamespace(config.client, pod.Name, pod.Namespace) Expect(err).NotTo(HaveOccurred()) </ins> cleanupLocalVolumes(config, []*localTestVolume{testVol}) }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /assign What happened: The tests are failing again because the scheduler messages have changed yet again. I'm going to remove the check for the exact messages because this is at least the 3rd time this has happened. Instead depend on unit/integration tests to check for specific failures. Also there's no need for these tests to run across all types of local volumes because it's just testing the scheduler part.
Code change:
// Checks whether stores for all clusters form the lists (and only these) are there and // are synced. func (fs *federatedStoreImpl) ClustersSynced(clusters []*federation_api.Cluster) bool { <del> fs.federatedInformer.Lock() defer fs.federatedInformer.Unlock() if len(fs.federatedInformer.targetInformers) != len(clusters) { </del> <ins> // Get the list of informers to check under a lock and check it outside. okSoFar, informersToCheck := func() (bool, []informer) { fs.federatedInformer.Lock() defer fs.federatedInformer.Unlock() if len(fs.federatedInformer.targetInformers) != len(clusters) { return false, []informer{} } informersToCheck := make([]informer, 0, len(clusters)) for _, cluster := range clusters { if targetInformer, found := fs.federatedInformer.targetInformers[cluster.Name]; found { informersToCheck = append(informersToCheck, targetInformer) } else { return false, []informer{} } } return true, informersToCheck }() if !okSoFar { </ins> return false } <del> for _, cluster := range clusters { if targetInformer, found := fs.federatedInformer.targetInformers[cluster.Name]; found { if !targetInformer.controller.HasSynced() { return false } } else { </del> <ins> for _, informerToCheck := range informersToCheck { if !informerToCheck.controller.HasSynced() { </ins> return false } }

Related discussion:
text: https://k8s- Failed: TestNamespaceController {namespace}
Code change:
package dns <del> import ( "fmt" "os" "testing" ) </del> var ( defaultResolvConf = "/etc/resolv.conf" // configurer.getHostDNSConfig is faked on Windows, while it is not faked on Linux. fakeGetHostDNSConfigCustom = getHostDNSConfig ) <del> // getResolvConf returns a temporary resolv.conf file containing the testHostNameserver nameserver and // testHostDomain search field, and a cleanup function for the temporary file. func getResolvConf(t *testing.T) (string, func()) { resolvConfContent := []byte(fmt.Sprintf("nameserver %snsearch %sn", testHostNameserver, testHostDomain)) tmpfile, err := os.CreateTemp("", "tmpResolvConf") if err != nil { t.Fatal(err) } cleanup := func() { os.Remove(tmpfile.Name()) } if _, err := tmpfile.Write(resolvConfContent); err != nil { cleanup() t.Fatal(err) } if err := tmpfile.Close(); err != nil { cleanup() t.Fatal(err) } return tmpfile.Name(), cleanup } </del>

Related discussion:
text: When a --resolv-conf (DNS resolver config) is passed to kubelet on a Windows node, the config content is used as part of sandbox initialization (through getHostDNSConfig()). Now with the recent changes (), it seems now to fail with an error like: E0315 10:22:16. 4764 ] "Error syncing pod, skipping" err="failed to "CreatePodSandbox" for "img-pull-(-b40a-459d-9033-)" with CreatePodSandboxError: "Failed to generate sandbox config for pod "img-pull-(-b40a-459d-9033-)": Unexpected resolver config value: "C:etckubernetescni". Expected "" or "Host"."" pod="img-puller-3842/img-pull-" podUID=-b40a-459d-9033- This is showing on all the runs of GCE testgrid (latest): Reading/using the passed resolv config on Windows Run a Windows pool with DNS resolv config being set as part of kubelet params. No response_ 27 alpha.3 1.27 beta.0 master <detailsGCE </details<details</details<details</details<details</details<details</details
/triage accepted /milestone v1.27 /sig node /sig network
/sig windows /cc
/priority criticial-urgent as this is likely a release blocking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority criticial-urgent 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
/priority critical-urgent
Hmm, so you're setting the [1]. This PR introduced the capability to read the DNS config options from the Windows host registries while removing the capability to read from a file, introducing a regression. I've sent a PR addressing this issue: [1]
Is the file you are pointing to a UNIX-style or something else?
Was the file changing the behavior of the node?
Code change:
package dns <del> import ( "fmt" "os" "testing" ) </del> var ( defaultResolvConf = "/etc/resolv.conf" // configurer.getHostDNSConfig is faked on Windows, while it is not faked on Linux. fakeGetHostDNSConfigCustom = getHostDNSConfig ) <del> // getResolvConf returns a temporary resolv.conf file containing the testHostNameserver nameserver and // testHostDomain search field, and a cleanup function for the temporary file. func getResolvConf(t *testing.T) (string, func()) { resolvConfContent := []byte(fmt.Sprintf("nameserver %snsearch %sn", testHostNameserver, testHostDomain)) tmpfile, err := os.CreateTemp("", "tmpResolvConf") if err != nil { t.Fatal(err) } cleanup := func() { os.Remove(tmpfile.Name()) } if _, err := tmpfile.Write(resolvConfContent); err != nil { cleanup() t.Fatal(err) } if err := tmpfile.Close(); err != nil { cleanup() t.Fatal(err) } return tmpfile.Name(), cleanup } </del>

Related discussion:
text: Yeah, what used on GCE/GKE, seems to be a Linux-like conf, eg: nameserver 10.128.0.1 search c.<project_name.internal google.internal ` We haven't tried to remove from kubelet to see the behavior.
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
I opened up a revert PR in case this PR does not merge by code freeze.
Thanks for the resolution! both 2019 and 2022 grids seems to be back to green now!
Thanks for confirming! I opened to ensure gets updated too
Code change:
if [[ ${ENABLE_METADATA_CONCEALMENT:-} == "true" ]]; then # Put the necessary label on the node so the daemonset gets scheduled. NODE_LABELS="${NODE_LABELS},cloud.google.com/metadata-proxy-ready=true" <del> # TODO(liggitt): remove this in v1.16 NODE_LABELS="${NODE_LABELS},beta.kubernetes.io/metadata-proxy-ready=true" </del> # Add to the provider custom variables. PROVIDER_VARS="${PROVIDER_VARS:-} ENABLE_METADATA_CONCEALMENT METADATA_CONCEALMENT_NO_FIREWALL" fi

Related discussion:
text: xref In 1.16: change the metadata-proxy addon to use change the kube-proxy addon to use change the masq-agent addon to use stop setting , , and in kube-up
Hey I'm trying to start to contribute to kubernetes and this seem to be an easy task. Can I help with this one?
Code change:
} } <del> // TODO: remove when storage.k8s.io/v1beta1 is removed. func newBetaStorageClass(t testsuites.StorageClassTest, suffix string) *storagev1beta1.StorageClass { pluginName := t.Provisioner if pluginName == "" { pluginName = getDefaultPluginName() } if suffix == "" { suffix = "default" } return &storagev1beta1.StorageClass{ TypeMeta: metav1.TypeMeta{ Kind: "StorageClass", }, ObjectMeta: metav1.ObjectMeta{ GenerateName: suffix + "-", }, Provisioner: pluginName, Parameters:  t.Parameters, } } </del> func startGlusterDpServerPod(c clientset.Interface, ns string) *v1.Pod { podClient := c.CoreV1().Pods(ns)

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.
Code change:
import ( "net/http" <ins> "os" </ins> "path/filepath" "github.com/gregjones/httpcache"

Related discussion:
text: In kubectl v1.8.0+, schema info is cached in the location specified by (defaulting to ), written with world-writeable permissions (rw-rw-rw-). If is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation. CVSS score: CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N (3.3, low) What versions are affected? kubectl v1.8.0+ What configurations are affected? Invocations that point at world-writeable locations Impact Malformed responses written to the cache directory can disrupt the kubectl invocation Workaround Use the default location in the $HOME directory or point it at a directory that is only accessible to desired users/groups. (original description follows) ==== What happened: The files inside of ".kube/http-cache" are world writeable (rw-rw-rw-). While the default for these files appears to be the home directory, using the "--cache-dir" flag could put these files into a place where world writeable files would allow any user / process to modify the cache files. Modification of the cache files could influence the kubectl utility in a negative way for other users. What you expected to happen: Apply stricter file permissions to the http-cache files. How to reproduce it (as minimally and precisely as possible): Run any generic kubectl command which is successful and then list the cache directory $ kubectl get pods --all-namespaces $ ls -la Anything else we need to know?
Code change:
import ( "net/http" <ins> "os" </ins> "path/filepath" "github.com/gregjones/httpcache"

Related discussion:
text: : I estimate this is a low severity security issue with a CVSS score of "3.3 / CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N" - Environment: Linux Kubernetes version (use kubectl version):Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-26T12:49:28Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-26T12:49:28Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: AWS. Running kube api server in hyperkube. OS (e.g: cat /etc/os-release): NAME="CentOS Linux" VERSION="7.1808 (Core)" ID="centos" IDLIKE="rhel fedora" VERSIONID="7" PRETTYNAME="CentOS Linux 7.1808 (Core)" ANSICOLOR="0;31" CPENAME="cpe:/o:centos:centos:7" HOMEURL="" BUGREPORTURL="" CENTOSMANTISBTPROJECT="CentOS-7" CENTOSMANTISBTPROJECTVERSION="7" REDHATSUPPORTPRODUCT="centos" REDHATSUPPORTPRODUCTVERSION="7" OSTREEVERSION=7.1808 Kernel (e.g. uname -a): Linux hackit.internal 3.10.0-862.11.6.el7.x8664 SMP Tue Aug 14 21:49:04 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Manual installation. Others: n/a
/sig product-security
Closing this issue. <detailsIn response to : if you think this is serious, send an email thanks!
Code change:
import ( "net/http" <ins> "os" </ins> "path/filepath" "github.com/gregjones/httpcache"

Related discussion:
text: </details
Adjusted the CVSS score to to indicate user interaction is required (since they must specify a non-default cache option pointed at a shared writeable location)
There are two places this should be done: PathPerm and FilePerm should be set here: the temp file and final file should have stricter permissions (probably 0660) here:
/cc
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
/assign
/assign I would like to work on release-1.9, as I just made a hot fix for our team's k8s version of 1.9.
GitHub didn't allow me to assign the following users: yuchengwu. 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 I would like to work on release-1.9, as I just made a hot fix for our team's k8s version of 1.9. 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
help fixing this is welcome, though it would only be fixed in releases 1.12+, per
/label official-cve-feed (Related to kubernetes/sig-security)