Question: return strings.HasPrefix(device, "/dev/loop") } <del> func parseLosetupOutputForDevice(output []byte) (string, error) { if len(output) == 0 { </del> <ins> // getLoopDeviceFromSysfs finds the backing file for a loop // device from sysfs via "/sys/block/loop*/loop/backing_file". func getLoopDeviceFromSysfs(path string) (string, error) { // If the file is a symlink. realPath, err := filepath.EvalSymlinks(path) if err != nil { </ins> return "", errors.New(ErrDeviceNotFound) } <del> // losetup returns device in the format: // /dev/loop1: [0073]:148662 (/var/lib/storageos/volumes/308f14af-cf0a-08ff-c9c3-b48104318e05) device := strings.TrimSpace(strings.SplitN(string(output), ":", 2)[0]) if len(device) == 0 { </del> <ins> devices, err := filepath.Glob("/sys/block/loop*") if err != nil { </ins> return "", errors.New(ErrDeviceNotFound) } <del> return device, nil </del> <ins> for _, device := range devices { backingFile := fmt.Sprintf("%s/loop/backing_file", device) // The contents of this file is the absolute path of "path". data, err := ioutil.ReadFile(backingFile) if err != nil { continue } // Return the first match. backingFilePath := strings.TrimSpace(string(data)) if backingFilePath == path || backingFilePath == realPath { return fmt.Sprintf("/dev/%s", filepath.Base(device)), nil } } return "", errors.New(ErrDeviceNotFound) </ins> }

I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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. 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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/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 </details


Question: import ( "context" <del> "fmt" </del> "net/http" "net/url" "sync/atomic"

/kind bug What happened: kube-aggregrator returns 500 status code with message: unable to set dialer for wardle/api as rest transport is of type *transport.debuggingRoundTripper What you expected to happen: 500 status code should not returned How to reproduce it (as minimally and precisely as possible): kube-apiserver with flag: sample-apiserver as said. command and get the 500 status code: Environment: community master
/assign
/sig api-machinery
/cc


Question: ip := pickNodeIP(c) testReachable(ip, nodePort) <ins> By("verifying the node port is locked") </ins> hostExec := LaunchHostExecPod(f.Client, f.Namespace.Name, "hostexec") <del> cmd := fmt.Sprintf(`ss -ant46 'sport = :%d' | tail -n +2 | grep LISTEN`, nodePort) </del> <ins> // Loop a bit because we see transient flakes. cmd := fmt.Sprintf(`for i in $(seq 1 10); do if ss -ant46 'sport = :%d' | grep ^LISTEN; then exit 0; fi; sleep 0.1; done; exit 1`, nodePort) </ins> stdout, err := RunHostCmd(hostExec.Namespace, hostExec.Name, cmd) if err != nil { Failf("expected node port (%d) to be in use, stdout: %v", nodePort, stdout)

cc
Reopening to remember to check if helped
No flakes in recent history
This just failed on PR Jenkins for me:
I've been hitting this one repeatedly in https://doc-0l3o4-0hqt8-s-
Access Denied for that link
Jenkins has already purged the link. Anyone who sees this - please open issues WITH THE ERROR MESSAGE if this pops up again. A Jenkins link is limited-lifetime.
this just re-occurred, here's the log:
Can you take a look, with prio, please. Of note:
I just randomly started debugging this because it caused a PR I was reviewing to fail e2es. I think the problem is the test is unaware that kube-proxies can fall behind each other. This is very likely because the "relist timeout" imposed on the watch is randomized server side, also one node could be low on cpu etc. Take a single failing case: To break down what happened: Created webserver-f0m07, tested it was up Picked some node (104.197.253.149) and tested reachability Scheduled hostexec pod on some node (e2e-gce-master-3-minion-w6ut, 104.197.244.14) Ran the ss command and checked for nodeport Evident from the following console logs: 09:05:09 Jan 27 09:04:45.111: INFO: Waiting up to 5m0s for pod webserver-f0m07 status to be running 09:05:09 Jan 27 09:04:45.119: INFO: Found pod 'webserver-f0m07' on node 'e2e-gce-master-3-minion-bcr0' 09:05:09 STEP: trying to dial each unique pod 09:05:09 Jan 27 09:04:45.278: INFO: Controller webserver: Got non-empty result from replica 1 [webserver-f0m07]: 1 of 1 required successes so far 09:05:09 STEP: hitting the pod through the service's NodePort 09:05:09 Jan 27 09:04:45.354: INFO: Successfully reached http://104.197.253.

149: 09:05:09 STEP: verifying the node port is locked 09:05:09 Jan 27 09:04:45.376: INFO: Waiting up to 5m0s for pod hostexec status to be running 09:05:09 Jan 27 09:04:57.437: INFO: Found pod 'hostexec' on node 'e2e-gce-master-3-minion-w6ut' 09:05:09 Jan 27 09:04:57.441: INFO: Running '/jenkins-master-data/jobs/kubernetes-pull-build-test-e2e-gce/workspace --server=https://104.197.246.4 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-pull-build-test-e2e- exec --namespace=e2e-tests-services-oht70 hostexec -- /bin/sh -c for i in $(seq 1 10); do if ss -ant46 'sport = :' | grep ^LISTEN; then exit 0; fi; sleep 0.1; done; exit 1' 09:05:09 STEP: deleting service nodeportservice-test in namespace e2e-tests-services-oht70 09:05:09 STEP: stopping RC webserver in namespace e2e-tests-services-oht70 09:05:09 [AfterEach] Services node the webserver pod landed on: node the hostexec pod landed on: Comparing kube-proxy logs from these 2 nodes we see that the second kubeproxy (hostexec) only actually processed the OnUpdate event for the node port at 17:05:17, which is actually waay later than the first kubeproxy sees it (17:04:40). To rule out clock skew I check when the kubelet on the first node saw the hostexec, and this matches up to roughly the time the kubelet on the second node saw the webserver pod (~17:45). To figure out where the skew comes from just check time between OnEndpointsUpdate log lines, you'll see the hostexec kubeproxy taking 2s at times (~17:04:29), while the webserver kube-proxy just whizzes along at 0.5s per update.

So I think the problems here are: 's no way to know that all kube-proxies have executed the nodeport actions for a service (i.e "service readiness") -proxy maybe processing OnUpdates in-efficiently, but that's not the core problem. test should either have a much larger timeout (the hostexec sh command above has seq(1 10)) and/or make sure it lands on the right host it has already verified preconditions for. The "service readiness" problem is a little deeper and will probably help ingress too.
chatted with Prashanth. He is investigating this.
And again today: gs://kubernetes-jenkins/logs/kubernetes-e2e-gce-parallel/ In the last 20 days this has failed ~9 times in that suite, only counting runs where only a few tests failed. 0.8% fail rate.
this is now assigned to you - plans for a fix?
for review
PR for fix is in.


Question: if !versFlag { allMountOptions = append(allMountOptions, fmt.Sprintf("%s=%s", vers, defaultVers)) } <ins> if !gidFlag && fsGroup != nil { allMountOptions = append(allMountOptions, fmt.Sprintf("%s=%d", gid, *fsGroup)) } </ins> return allMountOptions }

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.


Question: if t.String() == "*extensions.ReplicaSet" || t.String() == "*extensions.ReplicaSetList" { return []string{"CONTAINER(S)", "IMAGE(S)", "SELECTOR"} } <ins> if t.String() == "*api.Node" || t.String() == "*api.NodeList" { return []string{"EXTERNAL-IP"} } </ins> } return nil }

Nice to have for nodePort service debugging, creating manual firewalls, hitting hostNetwork or hostPort pods etc. Currently I need to either -o yaml, --template, or switch to gcloud.
This should be quite easy, should be good for contribution.
I could take a look at this. What information exactly that is available in yaml output should be shown? This is example yaml from my node: There should be an additional address with type , right? Should all types be supported or only external when is used?
-o wide should just dump what we get from the api-server right? What changes should be in kubectl?
-o yaml dumps apiserver outout, -o wide appends useful information at the cost of overflowing 80 chars. I'm asking that -o wide does for nodes what it already does for pods. I currently have such a function in my bash rc: I use it pretty often. That's a signal that more people are probably doing the same.
thanks!


Question: } go func() { <ins> mux := http.NewServeMux() </ins> if s.EnableProfiling { <del> http.HandleFunc("/debug/pprof/", pprof.Index) http.HandleFunc("/debug/pprof/profile", pprof.Profile) http.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </del> <ins> mux.HandleFunc("/debug/pprof/", pprof.Index) mux.HandleFunc("/debug/pprof/profile", pprof.Profile) mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </ins> } <del> http.Handle("/metrics", prometheus.Handler()) http.ListenAndServe(net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), nil) </del> <ins> mux.Handle("/metrics", prometheus.Handler()) server := &http.Server{ Addr:    net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), Handler: mux, } glog.Fatal(server.ListenAndServe()) </ins> }() configFactory := factory.NewConfigFactory(kubeClient)

goroutine 11 [running]: net/http.(ServeMux).Handle(0xc20800a8a0, 0x9e9490, 0xd, 0x7f7d12f190a0, 0xb0e7c0) +0x244 net/http.(ServeMux).HandleFunc(0xc20800a8a0, 0x9e9490, 0xd, 0xb0e7c0) +0x6d net/http.HandleFunc(0x9e9490, 0xd, 0xb0e7c0) +0x48 ·001() +0x58 created by (*SchedulerServer).Run +0x1c7
cc


Question: select { case <-stopCh: return nil <del> case <-r.initConnBackoffManager.Backoff().C(): </del> <ins> case <-r.backoffManager.Backoff().C(): </ins> continue } case apierrors.IsInternalError(err) && retry.ShouldRetry():

Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted


Question: }, Spec: experimental.DeploymentSpec{ Replicas:       3, <del> Selector:       podLabels, </del> <ins> Selector:       deploymentPodLabels, </ins> UniqueLabelKey: "deployment.kubernetes.io/podTemplateHash", Template: &api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: podLabels, </del> <ins> Labels: deploymentPodLabels, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.


Question: return nil, fmt.Errorf("metric %q not found", metricName) } <del> if metricFamily.GetMetric() == nil { return nil, fmt.Errorf("metric %q is empty", metricName) } </del> if len(metricFamily.GetMetric()) == 0 { return nil, fmt.Errorf("metric %q is empty", metricName) }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
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
/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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale


Question: return nil } <del> func NewContainerManager(mountUtil mount.Interface, cadvisorInterface cadvisor.Interface, nodeConfig NodeConfig) (ContainerManager, error) { </del> <ins> func NewContainerManager(mountUtil mount.Interface, cadvisorInterface cadvisor.Interface, nodeConfig NodeConfig, failSwapOn bool) (ContainerManager, error) { </ins> return &containerManagerImpl{}, nil }

Failed: https://k8s- Run so broken it didn't make JUnit output!
Looks like .
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!

Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Should be fixed by
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!


Question: set-broken-motd ensure-basic-networking fix-apt-sources <del> apt-get-update </del> ensure-install-dir ensure-packages set-kube-env

I noticed that there is a huge regression on node bootup since Wednesday last couple of days: Bad one: vs. good one: Please note that the issue is not related to any kubernetes component. The node hasn't run salt client yet. This explains a lot of node not ready issue we have lately. cc/
cc/
Whoa, it shouldn't even be running at all. That implies someone a package recently.
I didn't see any new package is , and the entire package size is the same. :-(
Can you dump /var/log/apt.history (I think it is) into here?
Sorry, . Hmm. I don't see anything new on a recent-ish head node, either, but YMMV.
Yes, just about to do it ... Here you are, and please note that it is from a different node with the same bad symptom:
Yeah, no issue there. Oh. Hm. Sorry, I forgot the one directly in .
Wait. The one in configure-vm is new, it's from , and we need to take it out.
Oh no - so sorry :-( does add an apt-get update to configure-vm. But you are installing bridge-utils from apt, so I thought it was correct to apt-get update first. I can easily remove the apt-get-update and add it back into the AWS version instead. In my experience, crazy-slow apt-get problems are either due to an IPv6 address being served to an IPv4 only host, or getting a bad mirror. Is there a GCE internal mirror? Could also be the gluster repo as well - not necessarily the debian repo.
Probably the bestest thing would be to make sure bridge-utils is on the base image, only apt-get-install bridge-utils if brctl is not available, and run apt-get-update as part of apt-get-install only once per script invocation. But this isn't actually fixing the problem. Something is seriously wrong if an apt-get update takes 12 minutes.
is actually built-in on (the later is a no-op, sorry). I went through an effort at some point to make sure that never needed to or anything, because we were having troubles like this.
I can work up a PR that will probably work for all parties.
Yes, that is the root cause and we want to remove all external dependencies at bootup time. Assign this to
Thanks & sorry again to all.


Question: var numCpusFunc = getNumberOnlineCPUs // Convert libcontainer stats to info.ContainerStats. <del> func setCpuStats(s *cgroups.Stats, ret *info.ContainerStats) { </del> <ins> func setCpuStats(s *cgroups.Stats, ret *info.ContainerStats, withPerCPU bool) { </ins> ret.Cpu.Usage.User = s.CpuStats.CpuUsage.UsageInUsermode ret.Cpu.Usage.System = s.CpuStats.CpuUsage.UsageInKernelmode <del> ret.Cpu.Usage.Total = 0 </del> <ins> ret.Cpu.Usage.Total = s.CpuStats.CpuUsage.TotalUsage </ins> ret.Cpu.CFS.Periods = s.CpuStats.ThrottlingData.Periods ret.Cpu.CFS.ThrottledPeriods = s.CpuStats.ThrottlingData.ThrottledPeriods ret.Cpu.CFS.ThrottledTime = s.CpuStats.ThrottlingData.ThrottledTime <ins> if !withPerCPU { return } </ins> if len(s.CpuStats.CpuUsage.PercpuUsage) == 0 { // libcontainer's 'GetStats' can leave 'PercpuUsage' nil if it skipped the // cpuacct subsystem.

/kind feature This is the once-per-release cut of a new cAdvisor release, which corresponds to the next kubernetes release. cAdvisor v0.29 corresponds to kubernetes v1.10. /sig node /priority important-soon
self-reminder to add per-cpu stats to ignore metrics when vendoring. reminder to add a release notice that one of the container labels fields is being removed.
/kind bug turns out most of the changes are bug-fixes
please mark this issue as approved-for-milestone, since it certainly seems to be, and it's now code slush. Thanks!


Question: } } <ins> // boolPtr returns a pointer to a bool func boolPtr(b bool) *bool { o := b return &o } </ins> func TestControllerRef(t *testing.T) { var replicas int32 = 1 f := fake.NewSimpleClientset(

Currently there's now way for a user to check what they entered in the DataSource field of a PVC create request. In the past, this wasn't as confusing because if one were to submit invalid info (unsupported Kind) the verification checks would fail and the request would be rejected with a helpful message indicating why. As of 1.14 that's no longer the case, a user is able to put anything they wish in these fields and the create is performed and they get a PVC, and there's no way for them to see what is or isn't set. Adding output of DataSource to would be useful, not only for invalid cases where the input might just get eaten, but also for users to have the ability to check for originating sources of their PVCs.
/sig storage
/assign
GitHub didn't allow me to assign the following users: me. 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 me 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
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


Question: physicalMounter.ResetLog() } <ins> func testSetUp(mounter volume.Mounter, metadataDir, volPath string) error { if err := mounter.SetUp(volume.MounterArgs{}); err != nil { return fmt.Errorf("Expected success, got: %v", err) } // Stat the directory and check the permission bits if !volumeutil.IsReady(metadataDir) { return fmt.Errorf("SetUp() failed, ready file is not created") } fileinfo, err := os.Stat(volPath) if err != nil { if os.IsNotExist(err) { return fmt.Errorf("SetUp() failed, volume path not created: %s", volPath) } return fmt.Errorf("SetUp() failed: %v", err) } if e, a := perm, fileinfo.Mode().Perm(); e != a { return fmt.Errorf("Unexpected file mode for %v: expected: %v, got: %v", volPath, e, a) } return nil } func testTearDown(unmounter volume.Unmounter, metadataDir, volPath string) error { if err := unmounter.TearDown(); err != nil { return err } if volumeutil.IsReady(metadataDir) { return fmt.Errorf("Teardown() failed, ready file still exists") } if _, err := os.Stat(volPath); err == nil { return fmt.Errorf("TearDown() failed, volume path still exists: %s", volPath) } else if !os.IsNotExist(err) { return fmt.Errorf("TearDown() failed: %v", err) } return nil } </ins> func TestPluginBackCompat(t *testing.T) { basePath, err := utiltesting.MkTmpdir("emptydirTest") if err != nil {

<!-- 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: There is a node in my cluster whose disk is full on root partition, I cleared the disk and then rebooted the node to recover it. After the reboot, the kube-proxy on that node got stuck in "ContainerCreating" status and never changes, and all other pods can't run properly since the kubeproxy is not runing. What you expected to happen: Kubeproxy on that node can run normally after the disk clean and reboot How to reproduce it (as minimally and precisely as possible): the disk full on root partition in my env, leave roughly 100k space on root partition would make this issue more reproduciblethis issue is kind of tricky, to reproduce it, one need to populate the disk repeatedly since some disk space would be cleared because of pod evictionthe kube-proxy got deleted and created repeatedly because of pod eviction and daemon-set mechanism, it would stuck in ContainerCreating status if the disk space is not enough for creating volume contents of kube-proxy configMap volume, the first pod error event is like: MountVolume.Setup failed for volume "kube-proxy" space left on device After it got stuck, the following pod error event woud repeat over and over, kube-proxy is trying to mount configMap volume but always fail MountVolume.Setup failed for volume "kube-proxy": stat /var/lib/kubelet/pods/{podid} no such file or directory the disk and reboot the reboot is neccesary to reproduce the issue, without the reboot the pod eviction would kick in to delete kube-proxy pod the kube-proxy woud stuck in ContainerCreating Status forever, restart kubelet has no effects on that, kube-proxy pod need to be mannully deleted to get recover kube-proxy pod can't mount configMap volume, the following error keeps repeating MountVolume.Setup failed for volume "kube-proxy": stat /var/lib/kubelet/pods/{podid} no such file or directory Anything else we need to know?

: After digging into this issue for a quite long time, i think the reason for this issue is: The configMap volume uses emptyDir internally to create the volume directory, after the directory is created, configMap volume failed to populate it with configMap content because the disk is full, then configMap volume calls emptyDir.tearDown() to clear the temp directory. The problem is that emptyDir uses a "ready" file under /var/lib/kubelet/pods/{podId}/plugin/.. to determine whether the directory is created or not, if the ready file is present, then it wouldn't create the directory. The tearDown method only remove the directory, it doen't remove the ready file, so after the first out of disk error, the diretory creation always get skipped, hence no such file or directory error repeat over and over. Environment: Kubernetes version (use ): v.1.11.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): cent os 7 Kernel (e.g. ): Install tools: kubeadm Others:
/sig storage
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
If it's any help, I just encountered this issue in kubelet v1.13.2 under Debian Stretch 9.5, after a restart. I was not out of disk space. Deleting the ready files from /var/lib/kubelet/pods/{podId}*/ helped.
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
Rotten issues close after 30d of inactivity.

Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen hit this just now with the same conditions as originally described, but without a reboot.
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen </details
/reopen
/remove-lifecycle rotten
Reopened this issue. <detailsIn response to : /reopen 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
Thanks ! this helped me get my cluster running after all pods were evicted and clearing space alone didn't fix the issue.


Question: } _, err := nc.federatedApiClient.Core().Namespaces().Finalize(updatedNamespace) if err != nil { <del> glog.Errorf("Failed to update namespace %s: %v", updatedNamespace.Name, err) nc.deliverNamespace(namespace.Name, 0, true) return </del> <ins> return fmt.Errorf("failed to finalize namespace: %v", err) </ins> } } // TODO: What about namespaces in subclusters ??? <del> err := nc.federatedApiClient.Core().Namespaces().Delete(updatedNamespace.Name, &api.DeleteOptions{}) </del> <ins> err = nc.federatedApiClient.Core().Namespaces().Delete(updatedNamespace.Name, &api.DeleteOptions{}) </ins> if err != nil { // Its all good if the error is not found error. That means it is deleted already and we do not have to do anything. // This is expected when we are processing an update as a result of namespace finalizer deletion. // The process that deleted the last finalizer is also going to delete the namespace and we do not have to do anything. if !errors.IsNotFound(err) { <del> glog.Errorf("Failed to delete namespace %s: %v", namespace.Name, err) nc.deliverNamespace(namespace.Name, 0, true) </del> <ins> return fmt.Errorf("failed to delete namespace: %v", err) </ins> } } <ins> return nil </ins> }

In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by


Question: pod, _ := newPod(t, "unmanaged") add(t, dc.podStore, pod) dc.sync(ctx, pdbName) ps.VerifyNoStatusError(t, pdbName) <ins> verifyUnsupportedControllerEventEmitted(t, dc) </ins> } // Check if the unmanaged pods are correctly collected or not

When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
Reopened this issue. <detailsIn response to : /reopen 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


Question: ignorable         bool } <ins> func (f *fakeExtender) Name() string { return "fakeExtender" } </ins> func (f *fakeExtender) IsIgnorable() bool { return f.ignorable }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : In pkg/scheduler/core/generic_scheduler# , add some debug info: each scheduler extender's score and its name for each pod, e.g. And we need add a function(e.g. ) in interface to get extender's name or similar identity. For , it might be enough to return its url . Why is this needed: If there are two or more scheduler extenders configured for scheduler(and we have now), it will be very useful to debug why kubelet nodes get so high/low score. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
Reiterating the mentions to trigger a notification: <detailsIn response to : /assign 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
Why don't you send a PR instead?
Thanks. PR is sent. PTAL.


Question: IpProtocol: aws.String("icmp"), FromPort:   aws.Int64(3), ToPort:     aws.Int64(4), <del> IpRanges:   []*ec2.IpRange{{CidrIp: aws.String("0.0.0.0/0")}}, </del> <ins> IpRanges:   ec2SourceRanges, </ins> } permissions.Insert(permission)

/kind feature What happened: When an ELB is provisioned as a LoadBalancer, the client traffic's security group rule can be scoped to specific ranges but the MTU discovery rule cannot. What you expected to happen: The MTU discovery security group rule source range is configurable or matches the values of Anything else we need to know?: The value appears to be . I operate in an environment where as a source range is generally disallowed. Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: AWS Others: ELB, not using ALB in this case
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
is there any plans to fix this issue in the near future?
yep, PR being worked on over here
I can see the fixed merged in to Kubernetes 1.12


Question: type PersistAuthProviderConfigForUser func(user string) restclient.AuthProviderConfigPersister <ins> type promptedCredentials struct { username string password string } </ins> // DirectClientConfig is a ClientConfig interface that is backed by a clientcmdapi.Config, options overrides, and an optional fallbackReader for auth information type DirectClientConfig struct { config         clientcmdapi.Config

When I want to use basic-auth, kubectl will display the password I entered: I think it is more sensible to hide the password?
And it seems that kubectl request for username/password twice...
I'll take this. There is a library here: That appears to do the trick, but we need some refactoring so that it can read from an arbitrary reader to fit our usecase.
This was fixed by but I didn't close this issue. Closing it now.


Question: var value0 uint64 var value1 uint64 = 10000000000 <ins> // Test with a large container of 100+ CPUs var value2 uint64 = 188427786383 </ins> tests := []struct { desc          string cpuUsageCache map[string]*cpuUsageRecord

What happened: CRI CPU metrics are incorrect when using a large number of cores, due to a overflow. What you expected to happen: CPU metrics should be correct for arbitrarily high numbers of cores. How to reproduce it (as minimally and precisely as possible): Deploy a pod with 20 CPU units allocated, and fetch the CRI metrics. The metrics will be incorrect. Environment: Kubernetes version (use ): 1.14.4 CRI: CRI-O cc cc /sig node /sig scalability
How did you get the cri cpu metrics?
kubelet /stats/summary API. For "large" pods, we confirmed that cri-o/cgroupfs calculations were being generated correctly and CPU data overflows at the kubelet CRI stats provider layer. Overflows of CPU data in /stats/summary results in metrics-server having bad data which further propagates to the HPA scaling Pods incorrectly.


Question: "k8s.io/kubernetes/pkg/volume" "github.com/golang/glog" <ins> "k8s.io/kubernetes/pkg/cloudprovider" "k8s.io/kubernetes/pkg/cloudprovider/providers/azure" </ins> "k8s.io/kubernetes/pkg/volume/util" ) <del> // This is the primary entrypoint for volume plugins. </del> <ins> // ProbeVolumePlugins is the primary endpoint for volume plugins </ins> func ProbeVolumePlugins() []volume.VolumePlugin { return []volume.VolumePlugin{&azureFilePlugin{nil}} }

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? NO Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubernetes, azure file, chinacloudapi Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others: What happened: We try to mount azure file to pod, and get the following error That is because azure china's storage DNS suffix is rather than What you expected to happen: Kubernetes should provide some method to let user specify storage dns suffix, so we can use Azure file volume How to reproduce it (as minimally and precisely as possible): Any Azure cluster in china can reproduce it. Anything else we need to know: kubernetes has hard coded in shows a relative issue
could you help confirm this?
One possible way is configuring DNS suffix via annotations of PV. If thinks this way okay, I'd like to create a PR to fix it.
azure file was implemented without using resource group or azure cloud provider. The endpoint can be found at One fix is to use azure cloud provider and choose the file service endpoint from azure environment as I did in blob service . Let me know if you can help.
I'm not familiar with azure cloud provider and volume codes. I'd like to try to dig into it to see if I can fix as the way you suggested.


Question: }, tests: []controllerTest{ { <del> name:            "15-3 - pvc storage class is not assigned retroactively if claim is already bound", </del> <ins> name:            "15-4 - pvc storage class is not assigned retroactively if claim is already bound but annotations are missing", </ins> initialVolumes:  novolumes, expectedVolumes: novolumes, <del> initialClaims:   newClaimArray("claim15-3", "uid15-3", "1Gi", "test", v1.ClaimBound, &classCopper, volume.AnnBoundByController, volume.AnnBindCompleted), expectedClaims:  newClaimArray("claim15-3", "uid15-3", "1Gi", "test", v1.ClaimLost, &classCopper, volume.AnnBoundByController, volume.AnnBindCompleted), </del> <ins> initialClaims:   newClaimArray("claim15-4", "uid15-4", "1Gi", "test", v1.ClaimBound, &classCopper), expectedClaims:  newClaimArray("claim15-4", "uid15-4", "1Gi", "test", v1.ClaimPending, &classCopper), </ins> expectedEvents:  noevents, errors:          noerrors, test:            testSyncClaim,

Presumably this would occur when changing the default from one class to another. E.g. Class X exists and is marked default Class Y is created Class Y is marked as default Uh oh!! 2 defaults Class X is marked as not default At the case in point, when there are 2 defaults, we currently do not assign default values to new PVCs. We should change this semantic - while there are two, pick one randomly or heuristically. It's still correct. Example: Suppose that you have one user changing the default and another user creating a PVC at exactly the same time. What happens? Depending on network, CPU scheduling, memory allocations, (etc - totally non-deterministic) the API server might see either of those operations first. The PVC creator will either win the race and get the old default class or it will lose the race and get the new default class. The difference could literally be whose network has a faster path to the API server. My point is that whichever one you pick, as long as it is one of those two defaults, it is a correct choice! Any other FooClass things we do should probably change, too. I think that's IngressClass and RuntimeClass.
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
GitHub didn't allow me to assign the following users: Octopusjust. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
picking either sounds reasonable but what if we allow only one default to be set and disallow/warn users if they try to create another default.

I can think of issues with this too, mainly when switching over to a new default by removing an existing class A and then setting B as a default but managing that orphaned period while the transition happens, maybe we can have the heuristic there? I'm sure I'm missing something here.
/assign
GitHub didn't allow me to assign the following users: Octopusjust. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
There is a problem when there is no default storage class for a while and another user creates a PVC. Such PVC won't get the new SC. We're trying to fix it in Until then, having two default storage classes for a brief moment is IMO slightly better, because at least users get an error message and can retry PVC creation. In addition, (in-tree) admission plugin in HA environment could be racy, as different API servers are admitting updates of different StorageClasses in parallel.
/assign
I wouldn't make 2 an error - just pick one.
Ok, I'd take a shot at this. Thanks for clearing things up.
+1 Still, having two default classes for a longer time is IMO bad, there should be a metric + alert if there are 2 or more default SCs for X minutes.
it's not ideal - a metric seems OK
hello there, im new to open source. i don't know how to contribute. can anyone hep me please?
I see this issue was labeled as "good first issue" and I would like to start working on it!
I see there is a pr related to this issue , are you still working on this?
Is this issue still open?
/assign
Yes, there's already a . It's linked to the issue itself.
The PR is specifically for StorageClass, but we also need to audit other FooClass things - they should probably change, too. I think that's IngressClass and RuntimeClass. Someone can open new PRs for these.
Oh, I see the second PR, too.

Will look at them ASAP
/remove-sig network
Do we emit a response header when someone makes a request that ends up setting two IngressClasses as default?
that seems a nice thing to do, I didn't know you can add warnings on admissions plugins but seems implemented it here
Is this issue still open??
StorageClass implementation is in I am not sure about those. I'd suggest opening separate issues. /close
Closing this issue. <detailsIn response to : whichever one you pick, as long as it is one of those two defaults, it is a correct choice! </details


Question: (disk.Vhd != nil && disk.Vhd.URI != nil && diskURI != "" && *disk.Vhd.URI == diskURI) || (disk.ManagedDisk != nil && *disk.ManagedDisk.ID == diskURI) { // found the disk <del> glog.V(4).Infof("azureDisk - find disk: lun %d name %q uri %q", *disk.Lun, diskName, diskURI) </del> <ins> glog.V(2).Infof("azureDisk - find disk: lun %d name %q uri %q", *disk.Lun, diskName, diskURI) </ins> return *disk.Lun, nil } }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Current logging is not enough for azure disk diagnostics, change some log level from 4 to 2 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: /sig azure /assign


Question: "containerA": runningState, "containerB": runningState, }, <del> Host: "machine", </del> <ins> Host: "machine-two", </ins> }, }, <del> api.PodRunning, "all running", </del> <ins> api.PodFailed, "all running but minion is missing", </ins> }, { &api.Pod{ Spec: desiredState, Status: api.PodStatus{ Info: map[string]api.ContainerStatus{ <del> "containerA": runningState, "containerB": runningState, </del> <ins> "containerA": stoppedState, "containerB": stoppedState, </ins> }, Host: "machine-two", }, }, api.PodFailed, <del> "all running but minion is missing", </del> <ins> "all stopped but minion missing", }, } for _, test := range tests { if status, err := getPodStatus(test.pod, fakeClient.Nodes()); status != test.status { t.Errorf("In test %s, expected %v, got %v", test.test, test.status, status) if err != nil { t.Errorf("In test %s, unexpected error: %v", test.test, err) } } } } func TestPodStatusWithRestartAlways(t *testing.T) { fakeClient := client.Fake{ MinionsList: api.NodeList{ Items: []api.Node{ { ObjectMeta: api.ObjectMeta{Name: "machine"}, }, }, }, } desiredState := api.PodSpec{ Containers: []api.Container{ {Name: "containerA"}, {Name: "containerB"}, }, RestartPolicy: api.RestartPolicy{Always: &api.RestartPolicyAlways{}}, } currentState := api.PodStatus{ Host: "machine", } runningState := api.ContainerStatus{ State: api.ContainerState{ Running: &api.ContainerStateRunning{}, }, } stoppedState := api.ContainerStatus{ State: api.ContainerState{ Termination: &api.ContainerStateTerminated{}, }, } tests := []struct { pod    *api.Pod status api.PodPhase test   string }{ {&api.Pod{Spec: desiredState, Status: currentState}, api.PodPending, "waiting"}, { &api.Pod{ Spec: desiredState, Status: api.PodStatus{ Info: map[string]api.ContainerStatus{ "containerA": runningState, "containerB": runningState, }, Host: "machine", }, }, api.PodRunning, "all running", </ins> }, { &api.Pod{

I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.


Question: }, }, SchemaProps: spec.SchemaProps{ <del> Description: "HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts file if specified. This is only valid for non-hostNetwork pods.", </del> <ins> Description: "HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts file if specified.", </ins> Type:        []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{

there is a note above hostAliases that this feature does not work with hostNework=true, yet it seems it does: when testing with a hostNetwork pod + hostAliases, there are no errors in kubelet logs at --v=10 related to this, in fact i don't see any hostAlias entries at all in there. i could not find anything blocking this in the kubelet, in fact there is normal handling of hostNetwork: i could not find any validation performed on the hostAliases field of PodSpec if hostNetwork is true on the API level. i could not find any unit tests or e2e tests related to this. the godoc should contain valid information if the feature is not supposed to work, it must be patched to not have the entries in the hosts file (perhaps?) we should have tests that ensure this type of requirement is guaranteed these steps confirm that a static pod with hostNework (deployed by kubeadm) does make use of hostAliases. create a kubeadm single node cluster directly with or one with modify the to include:wait some time for the new static pod spec to resync find the PID of the kube-apiserverget the hosts file n/a latest master 1.30.0-alpha.0 not applicable <details</detailskubeadm containerd v1.6.14 kindnet add test: update godoc:
/sig node network cluster-lifecycle /kind documentation
as reported by the hostAliases sometimes are not mounted for hostNetwork static pods, which is concerning: related slack thread:
At minimum the comment is wrong I need to be updated and we need e2e tests :/
found this, support was a while back: i will PR the API docs.
We identified an edge case here with Kubernetes v1.29. If a cloud provider did not yet initialise the node's , the code for creating the file including the hostAliases does not get run. To be concrete, in: is empty in this case which leads to to be . I was able to trace it back to this change which leads to this behaviour for static pods: For confirmation: I reverted the above commit, rebuilt kubelet and it got back to the old behaviour.

there is no perfect solution, but reverting is wrong because opens another bug, we need to study this more carefully but in the meantime installers that know the nodes addresses beforehand should set the --node-ip flag or not use cloud-provider external
yeah, as i mentioned downstream, revering is out of the question. it fixes some long standing problems. we might have to document somewhere this limitation in a cloud provider env.
i think it might be possible for us to special case this so that the hostAlias management does not wait for the node IP in a CP env, under certain conditions. just a speculation.
PRs add test: update godoc:
/triage accepted looks like it is being worked on already


Question: requests: cpu: 100m env: <del> - name: ELASTICSEARCH_URL </del> <ins> - name: ELASTICSEARCH_HOSTS </ins> value: http://elasticsearch-logging:9200 <ins> - name: SERVER_NAME value: kibana-logging </ins> - name: SERVER_BASEPATH value: /api/v1/namespaces/kube-system/services/kibana-logging/proxy <ins> - name: SERVER_REWRITEBASEPATH value: "false" </ins> ports: - containerPort: 5601 name: ui

What happened: On latest fluentd-elasticsearch, the elasticsearch replicas seems failed to form a valid cluster with the service discovery helper written in golang. What you expected to happen: Successfully boot up an elasticsearch cluster I guess. How to reproduce it (as minimally and precisely as possible): Just use the yamls in and the elasticsearch-logging pods will keep spamming warning messages. I think thats because options are deprecated in elasticsearch 7.x.x Anything else we need to know?: IMHO I think thats all. Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig instrumentation
Thanks


Question: apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" watch "k8s.io/apimachinery/pkg/watch" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount" "k8s.io/kubernetes/test/e2e/framework" e2ekubectl "k8s.io/kubernetes/test/e2e/framework/kubectl"

[X] Test approval issue: [X] Test PR: 5 Oct 2022 [X] Two weeks soak end date: 19 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. replaceCoreV1NamespacedServiceAccount Using a number of existing e2e test practices a new has been created for one ServiceAccount endpoint. The e2e logs for this test are listed below. This query shows which ServiceAccount endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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


Question: <ins> /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package main import ( "bytes" "encoding/json" "fmt" "io/ioutil" "log" "os" "os/exec" "sort" "strings" ) type Unwanted struct { // things we want to stop referencing Spec UnwantedSpec `json:"spec"` // status of our unwanted dependencies Status UnwantedStatus `json:"status"` } type UnwantedSpec struct { // TODO implement checks for RootModules // module names/patterns of root modules whose dependencies should be considered direct references RootModules []string `json:"rootModules"` // module names we don't want to depend on, mapped to an optional message about why UnwantedModules map[string]string `json:"unwantedModules"` } type UnwantedStatus struct { // TODO implement checks for Vendored // unwanted modules we still vendor, based on vendor/modules.txt content. // eliminating things from this list is good. Vendored []string `json:"vendored"` // TODO implement checks for distinguishing direct/indirect // unwanted modules we still directly reference from spec.roots, based on `go mod graph` content. // eliminating things from this list is good, and sometimes requires working with upstreams to do so. References []string `json:"references"` } // Check all unwanted dependencies and update its status. func (config *Unwanted) checkUpdateStatus(modeGraph map[string][]string) { fmt.Println("Check all unwanted dependencies and update its status.") for unwanted := range config.Spec.UnwantedModules { if _, found := modeGraph[unwanted]; found { if !stringInSlice(unwanted, config.Status.References) { config.Status.References = append(config.Status.References, unwanted) } } } // sort deps sort.Strings(config.Status.References) } // runCommand runs the cmd and returns the combined stdout and stderr, or an // error if the command failed. func runCommand(cmd ...string) (string, error) { output, err := exec.Command(cmd[0], cmd[1:]...).CombinedOutput() if err != nil { return "", fmt.Errorf("failed to run %q: %s (%s)", strings.Join(cmd, " "), err, output) } return string(output), nil } func readFile(path string) (string, error) { content, err := ioutil.ReadFile(path) // Convert []byte to string and print to screen return string(content), err } func stringInSlice(a string, list []string) bool { for _, b := range list { if b == a { return true } } return false } func convertToMap(modStr string) map[string][]string { modMap := make(map[string][]string) for _, line := range strings.Split(modStr, "n") { if len(line) == 0 { continue } deps := strings.Split(line, " ") if len(deps) == 2 { first := strings.Split(deps[0], "@")[0] second := strings.Split(deps[1], "@")[0] original, ok := modMap[second] if !ok { modMap[second] = []string{first} } else if stringInSlice(first, original) { continue } else { modMap[second] = append(original, first) } } else { // skip invalid line log.Printf("!!!invalid line in mod.graph: %s", line) continue } } return modMap } // difference returns a-b and b-a as a simple map. func difference(a, b []string) (map[string]bool, map[string]bool) { aMinusB := map[string]bool{} bMinusA := map[string]bool{} for _, dependency := range a { aMinusB[dependency] = true } for _, dependency := range b { if _, found := aMinusB[dependency]; found { delete(aMinusB, dependency) } else { bMinusA[dependency] = true } } return aMinusB, bMinusA } // option1: dependencyverifier dependencies.json // it will run `go mod graph` and check it. // option2: dependencyverifier dependencies.json mod.graph // it will check the specified mod graph result file. func main() { var modeGraphStr string var err error if len(os.Args) == 2 { // run `go mod graph` modeGraphStr, err = runCommand("go", "mod", "graph") if err != nil { log.Fatalf("Error running 'go mod graph': %s", err) } } else if len(os.Args) == 3 { modGraphFile := string(os.Args[2]) modeGraphStr, err = readFile(modGraphFile) // read file, such as `mod.graph` if err != nil { log.Fatalf("Error reading mod file %s: %s", modGraphFile, err) } } else { log.Fatalf("Usage: %s dependencies.json {mod.graph}", os.Args[0]) } dependenciesJSONPath := string(os.Args[1]) dependencies, err := readFile(dependenciesJSONPath) if err != nil { log.Fatalf("Error reading dependencies file %s: %s", dependencies, err) } // load Unwanted from json configFromFile := &Unwanted{} decoder := json.NewDecoder(bytes.NewBuffer([]byte(dependencies))) decoder.DisallowUnknownFields() if err := decoder.Decode(configFromFile); err != nil { log.Fatalf("Error reading dependencies file %s: %s", dependenciesJSONPath, err) } // Check and update status of struct Unwanted modeGraph := convertToMap(modeGraphStr) config := &Unwanted{} config.Spec.UnwantedModules = configFromFile.Spec.UnwantedModules config.checkUpdateStatus(modeGraph) needUpdate := false // Compare unwanted list from unwanted-dependencies.json with current status from `go mod graph` removedReferences, unwantedReferences := difference(configFromFile.Status.References, config.Status.References) if len(removedReferences) > 0 { log.Println("Good news! The following unwanted dependencies are no longer referenced:") for reference := range removedReferences { log.Printf("   %s", reference) } log.Printf("!!! Remove the unwanted dependencies from status in %s to ensure they don't get reintroduced", dependenciesJSONPath) needUpdate = true } if len(unwantedReferences) > 0 { log.Printf("The following unwanted dependencies marked in %s are referenced:", dependenciesJSONPath) for reference := range unwantedReferences { log.Printf("   %s (referenced by %s)", reference, strings.Join(modeGraph[reference], ", ")) } log.Printf("!!! Avoid updating referencing modules to versions that reintroduce use of unwanted dependenciesn") needUpdate = true } if needUpdate { os.Exit(1) } } </ins>

Add a file to track dependencies we want to remove or avoid picking back up. Examples: (as opposed to ) {analysis,spec,strfmt,validate} () and () () Add a presubmit that uses to do the following: if any items in the "unwanted but still present" list are no longer present and prompts to move them to the "absent and not allowed" list if any items in the "absent and not allowed" list are present and fails. Dependency updates often reintroduce problematic dependencies that were previously dropped. /area code-organization /cc
/sig architecture /triage accepted /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 : /sig architecture /triage accepted /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
I may help with it. /assign I checked the code, there is already a logic to check forbidden dependencies. can draw a go mod graph
yeah, that was sort of ad-hoc, and doesn't do the ratcheting bit we want (record a dependency we have but don't want, once we no longer use it, require moving it to the forbidden list)


Question: func TestGetZone(t *testing.T) { cloud := &Cloud{ Config: Config{ <del> Location: "eastus", </del> <ins> Location:            "eastus", UseInstanceMetadata: true, </ins> }, } testcases := []struct {

What happened: Currently starting Kubectl failing on Azure Stack. What you expected to happen: Kubectl should start on Azure Stack environment. How to reproduce it (as minimally and precisely as possible): Try to deploy Kubernets on Azure Stack environment.. Anything else we need to know?: Environment: Kubernetes version (use kubectl version): master Cloud provider or hardware configuration: OS (e.g: cat /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: /sig azure /assign
is it ? is a tool ...
my bad its kubelet. I update the title.
then could you provide the kubelet log? I am not sure kubelet on Azure stack is running as a container or process, you could get the logs by: And how do you deploy k8s on azure stack? cc


Question: "fmt" "io" "net" <ins> "strings" </ins> "time" csipbv1 "github.com/container-storage-interface/spec/lib/go/csi" "google.golang.org/grpc" api "k8s.io/api/core/v1" utilversion "k8s.io/apimachinery/pkg/util/version" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/klog" "k8s.io/kubernetes/pkg/features"

<!-- 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: If kubelet plugin registration fails during the registration process, the kubelet never attempts to register the socket again (assuming the error was transient), unless the socket for the driver is deleted & recreated to trigger a new registration. What you expected to happen: Maybe retry with exponential backoff when kubelet plugin registration fails instead of just logging and waiting for another filesystem event like it does today. Of course, if a socket returns a terminal error (does not implement the kubelet plugin registration service, for example), we should not retry. Follow up on /milestone v1.14 /sig storage 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
I'd like to work on this issue
/assign
Re opening. was a temporary work around for this. is the permanent fix.
Hello! We are starting Bug Freeze for 1.15. Is this issue still planned on being incorporated into 1.15?
the dependent PR is not yet merged. can we get this in for 1.15?
said that is the "permanent fix." and that has merged. So let's close this out /close
Closing this issue. <detailsIn response to : said that is the "permanent fix." and that has merged. So let's close this out 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


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> componentbaseconfig "k8s.io/component-base/config" )

What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after


Question: SelfLink          string    `json:"selfLink,omitempty" yaml:"selfLink,omitempty"` ResourceVersion   uint64    `json:"resourceVersion,omitempty" yaml:"resourceVersion,omitempty"` APIVersion        string    `json:"apiVersion,omitempty" yaml:"apiVersion,omitempty"` <del> Namespace         string    `json:"namespace",omitempty" yaml:"namespace,omitempty"` </del> <ins> Namespace         string    `json:"namespace,omitempty" yaml:"namespace,omitempty"` </ins> // Annotations are unstructured key value data stored with a resource that may be set by // external tooling. They are not queryable and should be preserved when modifying

For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.


Question: <ins> { "Rules": [ { "SelectorRegexp": "k8s[.]io/kubernetes/test/e2e", "AllowedPrefixes": [] } ] } </ins>

What happened: Integration tests import e2e test code today and the dependency makes two drawbacks. It is hard to move test/e2e/framework into staging () Need to run integration tests always even if PRs are just changing e2e test code This PR is for removing this dependency from integration tests. Target dependencies Following files are importing e2e test code from integration tests: [x] () [x] () [x] () and we need to put file for blocking such dependency anymore.
/sig testing /area code-organization
/remove-kind bug
/assign
for /assign


Question: t.Fatalf("unexpected faked discovery return value: %q", sv.GitCommit) } } <ins> func TestFakingServerVersionWithError(t *testing.T) { expectedError := errors.New("an error occurred") fakeClient := fakeclientset.NewSimpleClientset() fakeClient.Discovery().(*fakediscovery.FakeDiscovery).PrependReactor("*", "*", func(action kubetesting.Action) (handled bool, ret runtime.Object, err error) { return true, nil, expectedError }) _, err := fakeClient.Discovery().ServerVersion() if err == nil { t.Fatal("ServerVersion should return error, returned nil instead") } if err != expectedError { t.Fatal("ServerVersion should return expected error, returned different error instead") } } </ins>

<!-- 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: I was trying to write a test in a service I'm working on to catch if an error returns from . When I overrode the result of the fake client with a reactor to return an error I did not get the error back. What you expected to happen: If the reactor is set to return an error, it should come back. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This only happens with the fake. Environment: Kubernetes version (use ): 1.14 Cloud provider or hardware configuration: any OS (e.g: ): any Kernel (e.g. ): any Install tools: any Network plugin and version (if this is a network-related bug): n/a Others:
/sig testing
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
Let's take a look at this /priority important-longterm /sig api-machinery /remove-sig testing /remove-lifecycle rotten
Is there any progress?
I submited a PR to fix this issue. PTAL .
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
^^^ would it be possible to reconsider this PR? I ran into the same issue today.
this hasn't been fixed and we recently ran into this issue. Can we /reopen? Happy to bring up to date.
/reopen still relevant as above
Reopened this issue. <detailsIn response to : /reopen 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
/remove-lifecycle rotten /triage accepted
/assign


Question: expectedStatusCode: http.StatusInternalServerError, expectedBody:       "missing user", }, <del> "proxy with user": { </del> <ins> "proxy with user, insecure": { </ins> user: &user.DefaultInfo{ Name:   "username", Groups: []string{"one", "two"},

an APIService that routes to an external API server (e.g. service catalog) via a service in namespace a caBundle in the APIService the external API server with a certificate signed for Result: Normal API requests (get/put/post) work as expected Normal watch requests work as expected Upgrade requests (e.g. websocket watch requests) return a 500 error with text like cc


Question: test.run(t) } <ins> func TestUnsetUnexistConfig(t *testing.T) { conf := clientcmdapi.Config{ Kind:       "Config", APIVersion: "v1", Clusters: map[string]*clientcmdapi.Cluster{ "minikube":   {Server: "https://192.168.99.100:8443"}, "my-cluster": {Server: "https://192.168.0.1:3434"}, }, Contexts: map[string]*clientcmdapi.Context{ "minikube":   {AuthInfo: "minikube", Cluster: "minikube"}, "my-cluster": {AuthInfo: "mu-cluster", Cluster: "my-cluster"}, }, CurrentContext: "minikube", } test := unsetConfigTest{ description: "Testing for kubectl config unset a unexist map key", config:      conf, args:        []string{"contexts.foo.namespace"}, expectedErr: "current map key `foo` is invalid", } test.run(t) } </ins> func (test unsetConfigTest) run(t *testing.T) { fakeKubeFile, err := ioutil.TempFile(os.TempDir(), "") if err != nil {

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this 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
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug


Question: gidStr := strconv.FormatInt(int64(gid), 10) pv.Annotations = map[string]string{ <del> volumehelper.VolumeGidAnnotationKey:        gidStr, volumehelper.VolumeDynamicallyCreatedByKey: heketiAnn, glusterTypeAnn:                             "file", "Description":                              glusterDescAnn, v1.MountOptionAnnotation:                   "auto_unmount", </del> <ins> volumehelper.VolumeGidAnnotationKey: gidStr, "kubernetes.io/createdby":           "heketi-dynamic-provisioner", "gluster.org/type":                  "file", "Description":                       "Gluster: Dynamically provisioned PV", v1.MountOptionAnnotation:            "auto_unmount", </ins> } pv.Spec.Capacity = v1.ResourceList{

several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.


Question: return fmt.Errorf("error writing to %q: %v", filePath, err) } } else { <del> framework.Logf("nnTest Suite Metrics:n%snn", metricsJSON) </del> <ins> framework.Logf("nnTest Suite Metrics:n%sn", metricsJSON) </ins> } return nil

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is always appending a new line to its message: In some places of code, the message is already has a newline character and it leads to doubled new lines in the logs. What you expected to happen: I'm not sure what is the correct behavior here. One of the options could be to append a new line conditionally.
/sig testing
I'm new to Kubernetes and would like to start contributing. Is it ok if I assign myself this issue?
/assign MorrisLaw
GitHub didn't allow me to assign the following users: MorrisLaw. Note that only can be assigned. <detailsIn response to : /assign MorrisLaw 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
I can't assign this to myself, as I am not a member yet. But I am still going to take this issue.
I'll help him on reviews so assigning.


Question: import ( "fmt" <ins> "runtime" </ins> "strings" "testing" "time"

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: // We shouldn't get here. PreFilter already checked this. return statusUnschedulable(logger, "resourceclaim must be reallocated", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim)) case claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer: <del> // The ResourceClass might have a node filter. This is // useful for trimming the initial set of potential // nodes before we ask the driver(s) for information // about the specific pod. class, err := pl.classLister.Get(claim.Spec.ResourceClassName) if err != nil { // If the class does not exist, then allocation cannot proceed. return statusError(logger, fmt.Errorf("look up resource class: %v", err)) } if class.SuitableNodes != nil { // TODO (#113700): parse class.SuitableNodes once in PreFilter, reuse result. matches, err := corev1helpers.MatchNodeSelectorTerms(node, class.SuitableNodes) if err != nil { return statusError(logger, fmt.Errorf("potential node filter: %v", err)) </del> <ins> if selector := state.informationsForClaim[index].availableOnNode; selector != nil { if matches := selector.Match(node); !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclassName", claim.Spec.ResourceClassName) </ins> } <del> if !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclass", klog.KObj(class)) } } // Now we need information from drivers. schedulingCtx, err := state.initializePodSchedulingContexts(ctx, pod, pl.podSchedulingContextLister) if err != nil { return statusError(logger, err) </del> } <del> status := statusForClaim(schedulingCtx, pod.Spec.ResourceClaims[index].Name) if status != nil { </del> <ins> if status := state.informationsForClaim[index].status; status != nil { </ins> for _, unsuitableNode := range status.UnsuitableNodes { if node.Name == unsuitableNode { return statusUnschedulable(logger, "resourceclaim cannot be allocated for the node (unsuitable)", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim), "unsuitablenodes", status.UnsuitableNodes)

The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign


Question: // Implement support for limiting pids in nodes SupportNodePidsLimit featuregate.Feature = "SupportNodePidsLimit" <del> // owner: @wk8 // alpha: v1.14 // beta: v1.16 // // Enables GMSA support for Windows workloads. WindowsGMSA featuregate.Feature = "WindowsGMSA" // owner: @bclau // alpha: v1.16 // beta: v1.17 // GA: v1.18 // // Enables support for running container entrypoints as different usernames than their default ones. WindowsRunAsUserName featuregate.Feature = "WindowsRunAsUserName" </del> // owner: @RobertKrawitz // alpha: v1.15 //

Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /sig windows /milestone v1.20 /good-first-issue
This request has been marked as suitable for new contributors. 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 : Both WindowsGMSA and WindowsRunAsUserName feature gates have been GA since v1.18 and were scheduled to be removed in v1.20. /milestone v1.20 /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
/triage accepted
Hi, how can i help with that?
Delete the codes related to these two feature gates, because they have been GA and are enabled by default
Yup, feel free to assign the issue to yourselft and then remove the features gates from the file listed above and any other places they are used in code. Thanks!
Hey, can i take this up ?
/assign
It seems that proposed it first. You can communicate with him before you start.
ok sure
/assign
Hi, Sorry by delay, but i cant push the issue branch and receive: fatal: unable to access '': The requested URL returned error: 403 I already fill the form to contriburter. Any sugestion? Regards
Before you start, you can read
i already assing to CLA and make a new branch issue-. But when i push the branch my permission is denny. any tips? Tkz
Try forking the kubernetes/kubernetes repository and then creating the pull request from a branch in your personal github repository.
Tkz, I create a PR, but i received: cla/linuxfoundation — commit missing GitHub user but i already do it. Whats is wrong?
Ok, i found the error. My name in git was wrong. Sorry, Im waiting the result for PR. Tkz
Now, i waiting for
Hi everyone, Is normal waiting this itens, or I must provide then? Tkz
Ok, Em ter., 20 de out.

de 2020 às 15:47, Mark Rossetti < : Doutor em Ciência da Computação na UNICAMP
When your code is ready, you can pull a pr from your own repo to kubernetes' repo~~ Remember to read the connection I posted earlier and the sub-connections inside.
Hi , we already past the code freeze for v1.20 and the release is due next week. At this point in time, we are considering only changes which are release blocking. Hence, I am removing this from the v1.20 milestone. Please feel to ping us on if you feel otherwise. /milestone clear
Hey Is there anything that can be done here?
Hi ! can I take this? anything required?
Hi, yes of course. Nothing to relate. Em ter., 19 de jan. de 2021 às 13:24, coderfornow <: Doutor em Ciência da Computação na UNICAMP
/assign


Question: "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apiserver/pkg/server/storage:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/flag:go_default_library", <ins> "//vendor/k8s.io/klog:go_default_library", </ins> ], )

https://k8s- sample failure: (also affecting other CI jobs) cc /sig gcp
/assign We're interested in disabling the job as blocking entirely. We're of the opinion this shouldn't have bee allowed to block the community in the first place. I swear there's a historical issue around tightening the regex somewhere.
... wrong button sorry about that
possibly caused by erroring on invalid values that were previously silently skipped opened to downgrade that error to a warning for a release
Well, I mentioned the idea of making the job optional in
PR out to drop the runifchanged regex from pull-kubernetes-e2e-gke
Confirmed turns the test green
Can call this closed when merges
/pony hooray
Couldn't find a pony matching that query. <detailsIn response to : /pony hooray 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


Question: nextStartNodeIndex       int } <ins> type pluginScore struct { Name  string Score int64 } type pluginScoreList []pluginScore // NodeToPluginScores declares a map from node name to its PluginScoreList. type nodeToPluginScores map[string]pluginScoreList </ins> // snapshot snapshots scheduler cache and node infos for all fit and priority // functions. func (g *genericScheduler) snapshot() error {

/sig scheduling A way to check the scoring of each node to figure out why a node has a high scheduling priority. proposal 1: add some debug level logs to Kube-scheduler, so we can know node score on each scoring step. proposal 2: a simple way to decrease the priority of one node(in my case a node with more than 200 pods is with the highest scheduling priority for an unknown reason) proposal 3:? All new pods are scheduled to one of five nodes in my cluster. I have checked both CPU/memory requested usage and all five nodes are bare metal and running about 150 pods or 200 pods. Pods on node request 80-93% of the memory. We have a similar issue as Currently, I think is the easiest way.
This is useful. how do you suggest we log this information? note that there are two dimensions for each pod: plugin and node score. Also, we need to limit the log length, we can't simply log the score for each node in clusters with large number of nodes.
I prefer to log only the top 5 or 10 node scores in the log. (I have not read the code yet., will dig into it later.)
We actually merged something like this that I wrote in , but had to revert it because of performance issue in large clusters. That could be a good starting point My general approach was to 1) invert the already available to map (rather than , which it currently does) and then 2) log the top 3 highest scoring plugins for each node However discovered performance issues after this in (we believe due to the many writes this process took) and it was reverted in I think we decided that some performance hit is reasonable, especially given log levels =4, but this was ~50% drop.
thanks for the information. So with current kube-scheduler, I can set log level to 10 to get every node score for each plugin. It helps in some cases.
yes, that's the current case. Though creates a lot of other noise in the logs, so I think we agreed that it is okay for us to add this kind of summary at a lower level like
I think we can use this chance to standardize the logging logic to dump scores dynamically depending on log level: for logging level ranged in , dump the scores for topM nodes/plugins.

And make it as performant as possible. for logging level ranged in , dump the scores for topN nodes, and probably show all plugins for logging level = 10, dump the scores for all nodes/plugins.
/assign
/triage accepted
/reopen Some problems that were mentioned by are not fixed yet. /cc
Reopened this issue. <detailsIn response to : /reopen After taking a glance, I can spot several issues: A consensus on the value and . This is not fully discussed yet. Further dig into the performance result. The test runs on v=1 and v=4, but actually they're the same if it's running in the context of integration framework. I'd expect to see the result comparing before/after on v=4 and v=6. Further review on the code, like adding UTs and some logic nits. 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
Since is merged to revert the change,
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Just FYI: this may be related to in the future.

In , we cannot add all scores to the event message (because the event msg has the limit on the length), so I am thinking we need to sort node-scores by total score and add the score of top N nodes to the event msg. And, if we do so, we can easily achieve to log the top M Node's score by using this sorted node-scores.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/lifecycle rotten
/remove-lifecycle rotten
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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