jiebi/CodeConvo huggingface dataset:
Change:
"errors" "fmt" "io" <del> "net" </del> <ins> "io/ioutil" </ins> "net/url" "path" "path/filepath"

Discussion:
What keywords did you search in Kubernetes issues before filing this one?: VMware, vSphere, IP, UUID BUG REPORT. Kubernetes version: Environment: Cloud provider or hardware configuration: VMware vSphere 6.5.0 OS : Debian GNU/Linux 8.7 (jessie) Kernel : Install tools: Kargo What happened: Some containers were launched on a node with a name containing the hostname of a different node and the does not retrieve the right node name : Here is retrieved instead of . When using the VSphere Cloud provider, the node name is retrieved from the function in Since this PR (), the node data are retrieved based on the IP address instead of the UUID. The function gets all the IP address and check if one of the IP on any interface matches a VM on vSphere. The problem is that the docker0 interface has the same IP on all the nodes (usually 172.17.0.1) and this IP is referenced into VMware. As this IP may be the first to appear in the it will match the first VM that vSphere gives with the function and this can be any VM running Docker on vSphere. Thus, the provider has a big chance to not get the informations for the VM it is running on, leading to an inconsistent state in the cluster (wrong pod name for example). Anything else we need to know: An idea would be to first retrieve the VM name with the function and if no results use the IP address (and add an exclusion to not use the interface). What do you think ? If you think this might be the right way to do, we can try to propose the PR. Thanks for your feedback.
Wow, this very much is a bad, bad bug. It was introduced by one of my colleagues here at HPE. It's made worse if you run multiple Kubernetes clusters in the same vSphere Datacenter. I'll send a PR upstream tomorrow to resolve this. I think it's best to go back to using dmidecode, but maybe someone from VMware ( or ?) has another suggestion? This would still require root access, but I can't think of a better way to get the machine's ID.
Related issue Will dig in more. For now instead of making it a value determined runtime the deployment framework should have root privileges and can populate it as part of the cloud config post VM creation.
is my colleague.

A little more info and a few ideas. I would also support going back to ` (still requires root though). We could also have the following logic: Get UUID and use it to get the VM Name with FindByUUID if possible, If not, get the hostname and use FindByDNSName, If still nothing is found, keep the current logic, excluding docker0 from the interfaces we examine. However, I agree with that getting this from the cloud config may be the best and most reliable solution.
I'm working on a patch right now that will do the following: Add a VMUUID field to the cloud config If VMUUID is not set, will use Error out if neither one is available
PR is - if someone would like to review :)
Change:
{ "name": "etcd-container", {{security_context}} <del> "image": "{{ pillar.get('etcd_docker_repository', 'registry.k8s.io/etcd') }}:{{ pillar.get('etcd_docker_tag', '3.5.3-0') }}", </del> <ins> "image": "{{ pillar.get('etcd_docker_repository', 'registry.k8s.io/etcd') }}:{{ pillar.get('etcd_docker_tag', '3.5.4-0') }}", </ins> "resources": { "requests": { "cpu": {{ cpulimit }}

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
glog.Infof("Running in container %q", kl.resourceContainer) } <ins> err := kl.imageManager.Start() if err != nil { kl.recorder.Eventf(kl.nodeRef, "imageManagerFailed", "Failed to start ImageManager %v", err) glog.Errorf("Failed to start ImageManager, images may not be garbage collected: %v", err) } </ins> go kl.syncNodeStatus() // Run the system oom watcher forever. go util.Until(kl.runOOMWatcher, time.Second, util.NeverStop)

Discussion:
I'm trying to start 100-node cluster. I got the following error in kubelet: E0505 08:31:55. 5066 ] Failed to create kubelet: failed to initialize image manager: failed to start image manager: dial unix connection refused After ssh-ing I checked that docker is working by running . I guess it must be some kind of a race where kubelet starts before docker is ready. When I start 3-node cluster it works just fine. This happened to me 3 times in a row. Please add this to 1.0 milestone if necessary.
I've just exactly the same problem (when creating a 100-node cluster)
This is a bug in our initialization logical. We initialize image manager which needs to talk to docker at very early stage before docker is up yet. Later kubelet does a wait to make sure docker is up. We should either delay the initialization of image manager or handle docker unavailable better. Kubelet will be restarted by monit eventually, but this definitely slow down node initialization. I mark this for 1.0. Should be a simple fix if we just simply delay the initialization of image manager.
I'll go ahead and fix it (since I am mainly to blame :) )
Changed to P0 because asked us to only add P0 issues to v1.0 milestone.
Change:
// pods have been created. func WaitForPodsSuccess(c *client.Client, ns string, successPodLabels map[string]string, timeout time.Duration) error { successPodSelector := labels.SelectorFromSet(successPodLabels) <del> start, badPods := time.Now(), []api.Pod{} </del> <ins> start, badPods, desiredPods := time.Now(), []api.Pod{}, 0 </ins> if wait.PollImmediate(30*time.Second, timeout, func() (bool, error) { podList, err := c.Pods(ns).List(api.ListOptions{LabelSelector: successPodSelector})

Discussion:
https://k8s- Failed: BeforeSuite {Kubernetes e2e suite} Previous issues for this test:
Change:
testPassword        = "password" testServer          = "0.0.0.0" testServer2         = "0.0.1.1" <ins> testServerFQIN      = "ExAmple.com" </ins> testUserServer2     = "user1" testPasswordServer2 = "password1" testIncorrectServer = "1.1.1.1"

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: kube-controller-manager is unable to locate the credentials of the vCenter host, even though they are defined and cased identically to the hostname in the cloud-provider-config. What you expected to happen: vCenter hostname should not be case-sensitive, or should be documented that it is. It should successfully locate credentials from the manager How to reproduce it (as minimally and precisely as possible): to an upper-case name kube-controller-manager daemon to update the secret to provision storage with the "thin" storage class will stay suck in pending Anything else we need to know?: Log Messages: ` This appears to be induced by the way the vCenter server name is calculated when the secret containing the credentials is parsed[]. The credentialKey is converted to lower case and is then parsed to lookup the server name. Environment: Kubernetes version (use ): v1.14 Cloud provider or hardware configuration: vSphere OS (e.g: ): Unknown Kernel (e.g. ): Unknown Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area/provider/vmware
/area provider/vmware
Change:
const ( defaultStorageAccountType       = compute.StandardLRS defaultAzureDiskKind            = v1.AzureManagedDisk <del> defaultAzureDataDiskCachingMode = v1.AzureDataDiskCachingNone </del> <ins> defaultAzureDataDiskCachingMode = v1.AzureDataDiskCachingReadOnly </ins> ) type dataDisk struct {

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!--What happened: change azure disk host cache to ReadOnly The default value would lead to slow perf. And according to below doc: default host cache should be , the reason why we use “cachingMode: None” by default in k8s is that there is a famous disk bug due to this cachingMode setting( & ) which would lead to disk i/o error, and this issue has been fixed in the middle of this year by azure disk team. 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 ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Change:
} func TestTaintTolerationFilter(t *testing.T) { <del> unschedulable := framework.NewStatus(framework.UnschedulableAndUnresolvable, ErrReasonNotMatch) </del> tests := []struct { name       string pod        *v1.Pod

Discussion:
When trying to see why pods don't start using either kubectl get events or kubectl describe pod , the base message is not detailed enough. Warning FailedScheduling 5s (x4 over 65s) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. What would you like to be : Details of the taint and details of what it didn't tolerate Why is this needed: To get much much better debug information by default when trying to understand why pods can't launch.
/sig cli
/sig scheduling /priority important-longterm
/cc
/remove-sig cli
Those labels are not set on the issue: <detailsIn response to : /remove-sig cli </details
/good-first-issue
/assign starizard
Can I get an idea of what this would involve? I might be able to put some work on it.
I assume is taking this already. The error message is produced in We probably also require changes in to get the name of the missing toleration.
/remove-help
Change:
} type FilterPlugin struct { <del> numFilterCalled int </del> <ins> numFilterCalled int32 </ins> failFilter      bool rejectFilter    bool }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: integration-master Which test(s) are flaking: TestPostFilterPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
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 scheduling /remove-sig testing
/assign
Change:
restart count MUST remain zero. release: v1.9 file: test/e2e/common/node/container_probe.go <ins> - testname: Pod liveness probe, using grpc call, success codename: '[sig-node] Probing container should *not* be restarted with a GRPC liveness probe [NodeConformance] [Conformance]' description: A Pod is created with liveness probe on grpc service. Liveness probe on this endpoint will not fail. When liveness probe does not fail then the restart count MUST remain zero. release: v1.23 file: test/e2e/common/node/container_probe.go </ins> - testname: Pod liveness probe, using local file, no restart codename: '[sig-node] Probing container should *not* be restarted with a exec "cat /tmp/health" liveness probe [NodeConformance] [Conformance]'

Discussion:
Instructions: Tests in : should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe /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 : Instructions: Tests in : /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 : Instructions: Tests in : /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
/assign
/assign
/assign
/assign
Hi, I want to take this
Change:
options = append(options, "ro") } mountOptions = volume.JoinMountOptions(b.mountOptions, options) <del> mountOptions = appendDefaultMountOptions(mountOptions) </del> <ins> mountOptions = appendDefaultMountOptions(mountOptions, fsGroup) </ins> } err = b.mounter.Mount(source, dir, "cifs", mountOptions)

Discussion:
If I look at the code of azureFile plugin, it has fsGroup as an argument, but don't see its usage anywhere I also don't see anywhere explicitely stated that azureFile volume supports fsGroup.
/sig storage
For those landing here, a separate path to get the mount point to have the right permissions is to add this annotation to the PV metadata: This makes the plugin mount the volume in the Pod under those UID,GID. Obviously, this implies that one knows what those are for their workload in the container ...
If i create a PV like this, still mounted with the default root used into POD. StorageClass PV
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. Prevent issues from auto-closing with an comment. 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 cc Let's check whether works for azure file.
/sig azure
is another way to set groupid(gid) While according to this , we also need to support Here is the code about setting fsgroup from securityContext. I will enable this feature and do a test, it should be 3 lines of code. /assign
BTW, this is all for Linux(UserID, GroupID), is there an identical setting for Windows container?
No, setting user for volumes doesn't work on Windows. Only the rw/ro options are implemented.
According to my investigation, though I put the following code in azure file , it does not take effect. The reason is azure file(cifs) mount does not support gid setting after file system mount, by default would be 0(root) So in summary, set fsGroup code in azure file is useless, user could set gid by mountOptions in storage class, here is an Let me know if you hav any concern about this issue Update: Root cause is azure file(cifs) mount does not support gid setting after file system mount, while azure disk supports.
is this true, that cifs does not support guid setting?
Of course cifs support gid setting, see example: I mean cifs does not support second time gid setting, kind of differnet than azure disk.

Anyway, I am working on a PR to support if no gid setting in azure file storage class, while if both sets, only gid from storage class would be used.
while the code is quite different than just add below 3 lines of code, actually below does not work: I will show you the PR tomorrow.
Change:
} // NewConfigFlags returns ConfigFlags with default values set <del> func NewConfigFlags() *ConfigFlags { </del> <ins> func NewConfigFlags(usePersistentConfig bool) *ConfigFlags { </ins> impersonateGroup := []string{} insecure := false

Discussion:
/kind bug What happened: takes ~11 seconds when there are thousands of CRDs and is around 28KiB. logs the following message once per resource: Removing unnecessary entries from reduces the runtime by around ten seconds. What you expected to happen: only parses once, and therefore doesn't run unnecessarily slowly. How to reproduce it (as minimally and precisely as possible): shows the config being loaded multiple times (assuming you have multiple pods in the current cluster). Alternatively, add 10-15 clusters to and create ~3000 of a cheap resource (eg custom resources or empty config maps). Run on this resource and observe that it is unnecessarily slow. Anything else we need to know?: I've created a CPU profile using the latest CI build of kubectl, which shows ~12 seconds being spent in . Environment: Kubernetes version (use ): v1.12.1 (also Cloud provider or hardware configuration: GKE or minikube --vm-driver=none OS (e.g. from /etc/os-release): Debian Buster-like Kernel (e.g. ): 4.17.0
/sig cli
/assign
Same problem here. I have less resources but more contexts in my kubeconfig file. With 90 pods and ~300 contexts in the kubeconfig it also takes ~10 seconds for a simple kubectl get pods Note: I tried it with kubectl: 1.11.0, 1.12. With kubectl 1.10.5 the kubeconfig was loaded only once.
I'm unable to reproduce this as of the latest master. My kubeconfig is only loaded 4 times, no matter how many resources are loaded.
When I try a kubectl v1.13.0-alpha.3 against unfortunately a 1.9.11 Kubernetes Cluster I still have the problem: `
Maybe the bug is Linux-only? Presumably the kubeconfig location is different on different platforms, so maybe it has a different code path. I can repro on latest master:
I filed to fixed this. You can try to help validate it. Thanks.
Works for me, thanks!
Change:
} allErrs = append(allErrs, apivalidation.ValidatePodTemplateSpec(&spec.Template, fldPath.Child("template"), opts)...) <del> if spec.Template.Spec.RestartPolicy != api.RestartPolicyOnFailure && spec.Template.Spec.RestartPolicy != api.RestartPolicyNever { </del> <ins> // spec.Template.Spec.RestartPolicy can be defaulted as RestartPolicyAlways // by SetDefaults_PodSpec function when the user does not explicitly specify a value for it, // so we check both empty and RestartPolicyAlways cases here if spec.Template.Spec.RestartPolicy == api.RestartPolicyAlways || spec.Template.Spec.RestartPolicy == "" { allErrs = append(allErrs, field.Required(fldPath.Child("template", "spec", "restartPolicy"), fmt.Sprintf("valid values: %q, %q", api.RestartPolicyOnFailure, api.RestartPolicyNever))) } else if spec.Template.Spec.RestartPolicy != api.RestartPolicyOnFailure && spec.Template.Spec.RestartPolicy != api.RestartPolicyNever { </ins> allErrs = append(allErrs, field.NotSupported(fldPath.Child("template", "spec", "restartPolicy"), spec.Template.Spec.RestartPolicy, []string{string(api.RestartPolicyOnFailure), string(api.RestartPolicyNever)})) }

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: Deployed an cronJob with an empty and it defaulted to which is an invalid option: Leaving the key out completely has the same result What you expected to happen: The empty key to default to something valid like or . Also document what this default is, my proposal would be to have as default since some tasks can't be reran easily. But it might be nice to force as default to enforce the stateless mindset even for crons :) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I guess not but I am open for questions :) Environment: Kubernetes version (use ): 1.19.2
My guess would be /sig api-machinery If it is better practice to wait for the triage instead of guessing the sig, let me know :+1:
/sig api-machinery
/assign
/remove-sig api-machinery /sig apps
/assign
/triage accepted
Change:
set -o nounset set -o pipefail <ins> if [ "${DEBUG}" == "true" ]; then set -x fi </ins> cert_ip=$1 extra_sans=${2:-} cert_dir=${CERT_DIR:-/srv/kubernetes}

Discussion:
cluster/saltbase/salt/generate-cert/make-ca- sets but does not echo what it is doing, so in the case of an error there is no evidence of which command produced the error.
Change:
"Supplemental Groups Strategy: RunAsAny", } <ins> falseVal := false </ins> fake := fake.NewSimpleClientset(&policyv1beta1.PodSecurityPolicy{ ObjectMeta: metav1.ObjectMeta{ Name: "mypsp", }, Spec: policyv1beta1.PodSecurityPolicySpec{ <del> AllowedUnsafeSysctls: []string{"kernel.*", "net.ipv4.ip_local_port_range"}, ForbiddenSysctls:     []string{"net.ipv4.ip_default_ttl"}, </del> <ins> AllowPrivilegeEscalation: &falseVal, AllowedUnsafeSysctls:     []string{"kernel.*", "net.ipv4.ip_local_port_range"}, ForbiddenSysctls:         []string{"net.ipv4.ip_default_ttl"}, </ins> SELinux: policyv1beta1.SELinuxStrategyOptions{ Rule: policyv1beta1.SELinuxStrategyRunAsAny, },

Discussion:
What happened: When doing , the Allow Privileged Escalation output shows a hex-encoded value instead of a stringified boolean: What you expected to happen: Show the stringified boolean value instead. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Solution turned out to be simple. Change this line: to be instead of .
/sig cli
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
This was fixed with