Question: } } <ins> func TestPIDPressure(t *testing.T) { testCases := []struct { name                               string podsToMake                         []podToMake evictPodIndex                      int noPressurePIDUsage                 string pressurePIDUsageWithGracePeriod    string pressurePIDUsageWithoutGracePeriod string totalPID                           string }{ { name: "eviction due to pid pressure", podsToMake: []podToMake{ {name: "high-priority-high-usage", priority: highPriority, pidUsage: 900}, {name: "default-priority-low-usage", priority: defaultPriority, pidUsage: 100}, {name: "default-priority-medium-usage", priority: defaultPriority, pidUsage: 400}, {name: "low-priority-high-usage", priority: lowPriority, pidUsage: 600}, {name: "low-priority-low-usage", priority: lowPriority, pidUsage: 50}, }, evictPodIndex:                      3, // we expect the low-priority-high-usage pod to be evicted noPressurePIDUsage:                 "300", pressurePIDUsageWithGracePeriod:    "700", pressurePIDUsageWithoutGracePeriod: "1200", totalPID:                           "2000", }, } for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { podMaker := makePodWithPIDStats summaryStatsMaker := makePIDStats pods := []*v1.Pod{} podStats := map[*v1.Pod]statsapi.PodStats{} for _, podToMake := range tc.podsToMake { pod, podStat := podMaker(podToMake.name, podToMake.priority, podToMake.pidUsage) pods = append(pods, pod) podStats[pod] = podStat } podToEvict := pods[tc.evictPodIndex] activePodsFunc := func() []*v1.Pod { return pods } fakeClock := testingclock.NewFakeClock(time.Now()) podKiller := &mockPodKiller{} diskInfoProvider := &mockDiskInfoProvider{dedicatedImageFs: ptr.To(false)} diskGC := &mockDiskGC{err: nil} nodeRef := &v1.ObjectReference{Kind: "Node", Name: "test", UID: types.UID("test"), Namespace: ""} config := Config{ MaxPodGracePeriodSeconds: 5, PressureTransitionPeriod: time.Minute * 5, Thresholds: []evictionapi.Threshold{ { Signal:   evictionapi.SignalPIDAvailable, Operator: evictionapi.OpLessThan, Value: evictionapi.ThresholdValue{ Quantity: quantityMustParse("1200"), }, }, { Signal:   evictionapi.SignalPIDAvailable, Operator: evictionapi.OpLessThan, Value: evictionapi.ThresholdValue{ Quantity: quantityMustParse("1500"), }, GracePeriod: time.Minute * 2, }, }, } summaryProvider := &fakeSummaryProvider{result: summaryStatsMaker(tc.totalPID, tc.noPressurePIDUsage, podStats)} manager := &managerImpl{ clock:                        fakeClock, killPodFunc:                  podKiller.killPodNow, imageGC:                      diskGC, containerGC:                  diskGC, config:                       config, recorder:                     &record.FakeRecorder{}, summaryProvider:              summaryProvider, nodeRef:                      nodeRef, nodeConditionsLastObservedAt: nodeConditionsObservedAt{}, thresholdsFirstObservedAt:    thresholdsObservedAt{}, } // create a pod to test admission podToAdmit, _ := podMaker("pod-to-admit", defaultPriority, 50) // synchronize _, err := manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // we should not have PID pressure if manager.IsUnderPIDPressure() { t.Fatalf("Manager should not report PID pressure") } // try to admit our pod (should succeed) if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: podToAdmit}); !result.Admit { t.Fatalf("Admit pod: %v, expected: %v, actual: %v", podToAdmit, true, result.Admit) } // induce soft threshold for PID pressure fakeClock.Step(1 * time.Minute) summaryProvider.result = summaryStatsMaker(tc.totalPID, tc.pressurePIDUsageWithGracePeriod, podStats) _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // now, we should have PID pressure if !manager.IsUnderPIDPressure() { t.Errorf("Manager should report PID pressure since soft threshold was met") } // verify no pod was yet killed because there has not yet been enough time passed if podKiller.pod != nil { t.Errorf("Manager should not have killed a pod yet, but killed: %v", podKiller.pod.Name) } // step forward in time past the grace period fakeClock.Step(3 * time.Minute) // no change in PID stats to simulate continued pressure _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // verify PID pressure is still reported if !manager.IsUnderPIDPressure() { t.Errorf("Manager should still report PID pressure") } // verify the right pod was killed with the right grace period. if podKiller.pod != podToEvict { t.Errorf("Manager chose to kill pod: %v, but should have chosen %v", podKiller.pod.Name, podToEvict.Name) } if podKiller.gracePeriodOverride == nil { t.Errorf("Manager chose to kill pod but should have had a grace period override.") } observedGracePeriod := *podKiller.gracePeriodOverride if observedGracePeriod != manager.config.MaxPodGracePeriodSeconds { t.Errorf("Manager chose to kill pod with incorrect grace period.  Expected: %d, actual: %d", manager.config.MaxPodGracePeriodSeconds, observedGracePeriod) } // reset state podKiller.pod = nil podKiller.gracePeriodOverride = nil // remove PID pressure by simulating increased PID availability fakeClock.Step(20 * time.Minute) summaryProvider.result = summaryStatsMaker(tc.totalPID, tc.noPressurePIDUsage, podStats) // Simulate increased PID availability _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // verify PID pressure is resolved if manager.IsUnderPIDPressure() { t.Errorf("Manager should not report PID pressure") } // re-induce PID pressure fakeClock.Step(1 * time.Minute) summaryProvider.result = summaryStatsMaker(tc.totalPID, tc.pressurePIDUsageWithoutGracePeriod, podStats) _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // verify PID pressure is reported again if !manager.IsUnderPIDPressure() { t.Errorf("Manager should report PID pressure") } // verify the right pod was killed with the right grace period. if podKiller.pod != podToEvict { t.Errorf("Manager chose to kill pod: %v, but should have chosen %v", podKiller.pod.Name, podToEvict.Name) } if podKiller.gracePeriodOverride == nil { t.Errorf("Manager chose to kill pod but should have had a grace period override.") } observedGracePeriod = *podKiller.gracePeriodOverride if observedGracePeriod != int64(0) { t.Errorf("Manager chose to kill pod with incorrect grace period.  Expected: %d, actual: %d", 0, observedGracePeriod) } // try to admit our pod (should fail) if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: podToAdmit}); result.Admit { t.Fatalf("Admit pod: %v, expected: %v, actual: %v", podToAdmit, false, result.Admit) } // reduce PID pressure fakeClock.Step(1 * time.Minute) summaryProvider.result = summaryStatsMaker(tc.totalPID, tc.noPressurePIDUsage, podStats) podKiller.pod = nil // reset state _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // we should have PID pressure (because transition period not yet met) if !manager.IsUnderPIDPressure() { t.Errorf("Manager should report PID pressure") } // no pod should have been killed if podKiller.pod != nil { t.Errorf("Manager chose to kill pod: %v when no pod should have been killed", podKiller.pod.Name) } // try to admit our pod (should fail) if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: podToAdmit}); result.Admit { t.Fatalf("Admit pod: %v, expected: %v, actual: %v", podToAdmit, false, result.Admit) } // move the clock past the transition period fakeClock.Step(5 * time.Minute) summaryProvider.result = summaryStatsMaker(tc.totalPID, tc.noPressurePIDUsage, podStats) _, err = manager.synchronize(diskInfoProvider, activePodsFunc) if err != nil { t.Fatalf("Manager expects no error but got %v", err) } // we should not have PID pressure (because transition period met) if manager.IsUnderPIDPressure() { t.Errorf("Manager should not report PID pressure") } // no pod should have been killed if podKiller.pod != nil { t.Errorf("Manager chose to kill pod: %v when no pod should have been killed", podKiller.pod.Name) } // try to admit our pod (should succeed) if result := manager.Admit(&lifecycle.PodAdmitAttributes{Pod: podToAdmit}); !result.Admit { t.Fatalf("Admit pod: %v, expected: %v, actual: %v", podToAdmit, true, result.Admit) } }) } } </ins> func TestAdmitUnderNodeConditions(t *testing.T) { manager := &managerImpl{} pods := []*v1.Pod{

Hard eviction means we trigger eviction with no grace period while soft eviction means that we obey a grace period. Test should check for that.
I have opened a PR based on what I could understand using a debugger and the other tests. This is my first time contributing to the codebase. Happy to take brutal feedback.
Hi, i would like to support this issue. Let me know if any help is required.
/assign


Question: } } <del> func stringptr(val string) *string { return &val } </del> // overlyCautiousIllegalFileCharacters matches characters that *might* not be supported.  Windows is really restrictive, so this is really restrictive var overlyCautiousIllegalFileCharacters = regexp.MustCompile(`[^(w/.)]`)

The discovery cache for kubectl is defaulted to 10 minutes: That means that every 10 minutes of using against a cluster, it runs API requests against all group versions, which can take quite some time on clusters with many operators installed (like , , , etc.). I previously wrote that shows that every 10 minutes a simple makes 170 API requests against a test cluster, vs 4 API requests when the cache exists. That results in significant productivity implications against such clusters. Here is a time comparison between a request that runs the discovery cache vs one that doesn't: The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers. This issue is raised to change the discovery cache default to 24 hours and also to make the discovery cache ttl configurable. Running the discovery cache every 10 minutes has a significant productivity impact on using on clusters with many CRDs as it is taking time to run these unnecessary requests. The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
I would like to work on this issue.
/assign


Question: {"release/v1.7.0", "https://dl.k8s.io/release", "v1.7.0", true}, {"release/latest-1.7", "https://dl.k8s.io/release", "latest-1.7", true}, // CI builds area, lookup actual builds at ci-cross/*.txt <ins> {"ci/latest", "https://dl.k8s.io/ci", "latest", true}, </ins> {"ci-cross/latest", "https://dl.k8s.io/ci-cross", "latest", true}, <del> {"ci/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </del> <ins> {"ci/latest-1.7", "https://dl.k8s.io/ci", "latest-1.7", true}, {"ci-cross/latest-1.7", "https://dl.k8s.io/ci-cross", "latest-1.7", true}, </ins> // unknown label in default (release) area: splitVersion validate only areas. {"unknown-1", "https://dl.k8s.io/release", "unknown-1", true}, // unknown area, not valid input.

https://k8s- /kind bug /sig cluster-lifecycle /milestone v1.10 /priority failing-test cc also cc should this even be in 1.10 blocking dashboard?
/priority critical-urgent (who owns this?)
(also https://k8s-)
Is this actually running now? /cc
It looks like it's failing to up the cluster, I don't remember what the previous status of this job was, I thought all kubeadm 1.10 jobs were running previously...
The reason this failed was the cross CI job was failing to push the images that are used by that job. /cc
/subscribe
the latest cross build for 1.9 is as following We seem to have only one job that does cross builds on master : https://k8s-*build&i=nope&files=&repos=test-infra So the job fails ( for example in )
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<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: ############################ if kube::test::if_supports_resource "${pods}" ; then <del> record_command run_kubectl_all_namespace_tests </del> <ins> if kube::test::if_supports_resource "${nodes}" ; then record_command run_kubectl_all_namespace_tests fi </ins> fi ################

This is wrong, cluster scoped resources should never have a NAMESPACE column. We need to fix and add a test to ensure this doesn't regress.
The presence of the flag is what triggers this.
I would help fix it.
I mean to add a test after modification, but found that current test framework could not support the case: To cover the scene, we need a real NewHumanReadablePrinter in test case, to ensure the output format, and modify the related funcs in FakeFactory to support pass in param withNamespace. I feel this not like behavior of unit test to some extent. The loss may outweighs the gain to have such a big impact on the whole. What's your opinion
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: } } <ins> // Create PVs for _, pvConfig := range test.pvs { pv := makePV(pvConfig.name, sharedClasses[pvConfig.scMode].Name, pvConfig.preboundPVC, config.ns, pvConfig.node) if _, err := config.client.CoreV1().PersistentVolumes().Create(pv); err != nil { t.Fatalf("Failed to create PersistentVolume %q: %v", pv.Name, err) } } </ins> // Create pod if _, err := config.client.CoreV1().Pods(config.ns).Create(test.pod); err != nil { t.Fatalf("Failed to create Pod %q: %v", test.pod.Name, err)

Add test for "on PVC add", see Test for "on PVC update" is not needed, because it has already been tested in all volume scheduling tests.
/sig
docs:


Question: <g> <rect style="fill: #ffffff" x="165.958" y="389.5" width="115" height="54"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="165.958" y="389.5" width="115" height="54"/> <del> <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="223.458" y="412.4"> </del> <ins> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="223.458" y="412.4"> </ins> <tspan x="223.458" y="412.4">authorization</tspan> <tspan x="223.458" y="428.4">authentication</tspan> </text>

Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc


Question: //   "-c",      - Index 1 //   "exec /usr/local/bin/kube-apiserver " - Index 2 execArgsIndex        = 2 <del> encryptionConfigFlag = "--experimental-encryption-provider-config" </del> <ins> encryptionConfigFlag = "--encryption-provider-config" </ins> ) testCases := []struct {

Ref Ref ref /sig auth /kind feature /milestone v1.11 /priority important-longterm /status approved-for-milestone cc
What's need to be done here? I can think only about renaming to and updating the docs. What else?
What's required to promote encryption at rest with static configs to beta?
an example of promoting flags is here: If there's a feature gate, we're going to want to enable it by default too.
/assign
submitted PRs for that: and
[MILESTONENOTIFIER] Milestone Removed From Issue Important: Code freeze is in effect and only issues with may remain in the v1.11 milestone. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Will this make it to Beta in 1.12? From sig-auth on 7/11, it sounded like this was missing a release shepherd. Is anyone owning pushing this forward?
I'll do my best to push this. edit: I did not realize that 1.12 feature freeze is today (or so I heard), I don't think I'll be able to make it :slightlyfrowningface:
Ack - that's what I was wondering (with the feature freeze). Thanks
- Is this making it to the 1.12 ?
The current plan is 1.13


Question: m := make(api.PodInfo) for k, v := range r.Status.Info { v.Ready = true <del> v.PodIP = "1.2.3.4" </del> m[k] = v } r.Status.Info = m

Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.


Question: // InstanceType returns the type of the specified instance. func (m *metadata) InstanceType(name types.NodeName) (string, error) { instanceType, err := m.get(metadataTypeInstanceType) <del> if err == nil { </del> <ins> if err != nil { </ins> return "", fmt.Errorf("could not get instance type: %v", err) }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: kubelet throws the exception when --cloud-provider=cloudstack is included: What you expected to happen: There shouldn't be an exception. How to reproduce it (as minimally and precisely as possible): Add the following line to /etc/systemd/system/kubelet.service.d/10- Environment="KUBELETEXTRAARGS=--cloud-provider=cloudstack --cloud-" and also configure the file. Anything else we need to know?: The condition check in the InstanceType() function in is wrong. It currently reads: but the correct code is (condition negated): Environment: Kubernetes version (use ): 1.8 Cloud provider or hardware configuration: cloudstack OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-98-generic Install tools: kubeadm Others: /sig cloudstack
I will have a look
/sig cluster-lifecycle /area cloudprovider


Question: ginkgo.By("checking if the expected cpuset was assigned") cpuListString = "1-2" <del> if isHTEnabled() { </del> <ins> if isMultiNUMA() { cpuList = cpuset.MustParse(getCoreSiblingList(0)).ToSlice() if !isHTEnabled() { cset = cpuset.MustParse(fmt.Sprintf("%d,%d", cpuList[1], cpuList[2])) } else { cset = cpuset.MustParse(getCPUSiblingList(int64(cpuList[1]))) } cpuListString = fmt.Sprintf("%s", cset) } else if isHTEnabled() { </ins> cpuListString = "2-3" cpuList = cpuset.MustParse(getCPUSiblingList(0)).ToSlice() if cpuList[1] != 1 {

Which jobs are failing: N/A - AFAICT CI jobs works fine Which test(s) are failing: Since when has it been failing: no historical record on CI Testgrid link: N/A Reason for failure: I believe the tests make too many assumptions around the hardware, and the code is actually OK. to be confirmed. Anything else we need to know:
/sig node /sig testing
also affects the recently topology manager e2e tests. My PR uses a different approach to check resource alignment so is not affected. /cc
I'll work on a PR to fix this issue ASAP
Thanks for opening this issue. We knew about this, just had not opened an issue to track it, so thanks for doing that! Deepthi has been looing at CPU Manager tests, not sure if she has some PR in progress or not. I'll make sure to forward this to her (can find her user id here ....) in case she has something in progress


Question: "command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When kube-apiserver's livenessProbe suggests that pod is unhealthy, kubelet tries to kill its container with 30 seconds grace period. The container is killed ungracefully with SIGKILL when grace period passes. This happens each time. What you expected to happen: I expected that SIGTERM will be passed to kube-apiserver which will try to gracefully stop before 30 seconds pass (at least in some cases). How to reproduce it (as minimally and precisely as possible): Inject kube-apiserver failure (e.g. ) Watch kubelet logs for container's death You will see that container is killed after 30 seconds each time Anything else we need to know?: I believe the problem is that in kube-apiserver.manifest uses '/bin/sh -c CMD' as a PID1 process which doesn't pass SIGTERM signals to child process. See Environment: Kubernetes version (use ): v1.7.11
/sig node
Looks like without the pipe command will have to be removed which will make the logs hard to track. There is indeed some which makes kube-apiserver run in background and trapping SIGTERM then send a SIGTERM to apiserver's PID.
I think this is the case for all our components, not just kube-apiserver. - FYI
How about using 'exec'-based solution suggested here: In our case it means prepending 'exec': I did changed this in my cluster and the process seems to meet requirements: fd/1 and fd/2 are redirected to /var/log/kube- container is killed instantaneously If everyone is fine with such a solution, I can prepare PR adding 'exec ' in front of all kubernetes/cluster/saltbase/salt/kube-apiserver/*.manifest using '/bin/sh -c CMD' pattern.
Not sure if understand what you mean. Before there was no logs, so /bin/sh -c wasn't needed. -based solution seems to have all required properties. What is your concern about using it?
Umm. just ignore my previous comment. I just tried prepending and it works fine for me.


Question: "command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- 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 ): 3 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: All of the salt scripts bundled in kubernetes (for example, ) start up the component in a broken way. They use which means the shell will intercept all signals. So these daemons are not gracefully shutdown when the pod is stopped. This causes serious problems since when apiserver is killed abruptly it doesn't seem to close watches correctly. This was observed in for example. What you expected to happen: Running is incorrect. It should run the binary directly. Otherwise, it needs to perform an so the binary correctly replaces the shell script process. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver inside a container with and try to stop it. You can't - eventually docker will force kill it. Anything else we need to know:
It looks like we changed from running the binaries directly to using in (from a few years ago to enable us to capture logs. or may recall why we had to use a shell since they reviewed that PR.
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.


Question: "command": [ "/bin/sh", "-c", <del> "/usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </del> <ins> "exec /usr/local/bin/kube-controller-manager {{params}} 1>>/var/log/kube-controller-manager.log 2>&1" </ins> ], {{container_env}} "livenessProbe": {

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


Question: pod, err = f.Client.Pods(f.Namespace.Name).Create(pod) Expect(err).To(HaveOccurred()) <ins> By("Ensuring a pod cannot update its resource requirements") // a pod cannot dynamically update its resource requirements. requests = api.ResourceList{} requests[api.ResourceCPU] = resource.MustParse("100m") requests[api.ResourceMemory] = resource.MustParse("100Mi") podToUpdate.Spec.Containers[0].Resources.Requests = requests _, err = f.Client.Pods(f.Namespace.Name).Update(podToUpdate) Expect(err).To(HaveOccurred()) By("Ensuring attempts to update pod resource requirements did not change quota usage") err = waitForResourceQuota(f.Client, f.Namespace.Name, quotaName, usedResources) Expect(err).NotTo(HaveOccurred()) </ins> By("Deleting the pod") err = f.Client.Pods(f.Namespace.Name).Delete(podName, api.NewDeleteOptions(0)) Expect(err).NotTo(HaveOccurred())

The scenario that presented a problem was the following: a) create pods in a namespace that do not make a memory claim b) add a quota that tracks memory c) update one of the pods previously created by reducing its active deadline. Expected result: Since a pod cannot change its resources via update, we should have been allowed to update the pod spec. Actual Result: error since the pod did not make a memory claim, quota rejects the pod.
cc


Question: <ins> /* Copyright 2019 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 plugins import ( "fmt" "reflect" "testing" ) func TestIsManagedDisk(t *testing.T) { tests := []struct { options  string expected bool }{ { options:  "testurl/subscriptions/12/resourceGroups/23/providers/Microsoft.Compute/disks/name", expected: true, }, { options:  "test.com", expected: true, }, { options:  "HTTP://test.com", expected: false, }, { options:  "http://test.com/vhds/name", expected: false, }, } for _, test := range tests { result := isManagedDisk(test.options) if !reflect.DeepEqual(result, test.expected) { t.Errorf("input: %q, isManagedDisk result: %t, expected: %t", test.options, result, test.expected) } } } func TestGetDiskName(t *testing.T) { mDiskPathRE := managedDiskPathRE uDiskPathRE := unmanagedDiskPathRE tests := []struct { options   string expected1 string expected2 error }{ { options:   "testurl/subscriptions/12/resourceGroups/23/providers/Microsoft.Compute/disks/name", expected1: "name", expected2: nil, }, { options:   "testurl/subscriptions/23/providers/Microsoft.Compute/disks/name", expected1: "", expected2: fmt.Errorf("could not get disk name from testurl/subscriptions/23/providers/Microsoft.Compute/disks/name, correct format: %s", mDiskPathRE), }, { options:   "http://test.com/vhds/name", expected1: "name", expected2: nil, }, { options:   "http://test.io/name", expected1: "", expected2: fmt.Errorf("could not get disk name from http://test.io/name, correct format: %s", uDiskPathRE), }, } for _, test := range tests { result1, result2 := getDiskName(test.options) if !reflect.DeepEqual(result1, test.expected1) || !reflect.DeepEqual(result2, test.expected2) { t.Errorf("input: %q, getDiskName result1: %q, expected1: %q, result2: %q, expected2: %q", test.options, result1, test.expected1, result2, test.expected2) } } } </ins>

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Azure is not listed as "migratable" in could refer to Why is this needed:
/sig azure /assign


Question: v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Unknown yet. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig scheduling /help
Can I give it a try?
Sure, feel free to take it. /assign ahmad-diaa /remove-help
I keep trying to get it fail locally by running the following command: but it never does, am I doing something wrong? Is there something else that I should be doing and would be more helpful?
Sometimes the flake is hard to reproduce in local env. You may have to read the error log of the flakes thoroughly to get some clues. BTW: you can also run the test multiple times using the directive:
After looking through the logs I came up with some information that might be useful As far as I understand, the reason for the flake is the of the medium priority pod not being cleared That is because the update request for removing returns the following error: So my current guess is that might be outdated in some cases As I am not really familiar with the logic, I would like to know whether or not those are valid points so that I could dig deeper. What do you think?
If that's the case, you can set here: You can raise a PR and manually try for ~20 times to see you can reproduce the flake.
found another issue tracking this too. it seems it has been flaky for a while.
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution.
This sometimes happens. But we usually take the first PR unless it's clearly worked by someone. In terms of which style to resolve the Conflict error, I'm asking here:
Sorry, didn't mean to take this one for you. I worked the duplicate issue and submitted a PR. Feel free to review that PR, or submit your own if you have a different solution. No worries, I haven't started implementing yet and your PR seems to be following the correct approach as well according to this:


Question: v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: [TODO] Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig node These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.


Question: v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" coreinformers "k8s.io/client-go/informers/core/v1"

Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestNominatedNodeCleanUp Testgrid link: Reason for failure: /sig scheduling
/assign
any progress on this one?
I was working on it and tried to find the root cause. I will give my solution within this week
Another one
Still happening cc
/assign
/close dupe
Closing this issue. <detailsIn response to : /close dupe 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: } } os.Remove(dir) <del> // TODO: we should really eject the attach/detach out into its own control loop. detachDiskLogError(b.cinderVolume) </del> glog.Errorf("Failed to mount %s: %v", dir, err) return err }

while reading some cinder code, i came accross , we try to detach disk even if we didn't try to mount. Is this call mandatory ? (from what i recall AWS EBS do not have such mecanism) Also ping
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig openstack
cc
that's was before attach/detach controller, a revisit is necessary
Sure i'll take care of it /assign


Question: path       string apiService *apiregistration.APIService <ins> serviceResolver ServiceResolver </ins> expectedStatusCode int expectedBody       string expectedCalled     bool

https://k8s- https://k8s- https://k8s- https://k8s- https://k8s- ... A lot of them /cc
/assign
Still see this failure after is merged, although less frequently: https://k8s- https://k8s- Reopen.
Looks like the client doesn't differentiate between 500 and 503 here: It should. Will open a fix shortly
opened
fix merged, will monitor https://k8s-
Thanks! :)
haven't seen this in the 12 hours since the fix merged, was seeing it every 2-3 hours before. /close


Question: wantEvents: []framework.ClusterEvent{queue.NodeTaintChange}, }, { <ins> name:       "only node annotation changed", newNode:    st.MakeNode().Annotation("foo", "bar").Obj(), oldNode:    st.MakeNode().Annotation("foo", "fuz").Obj(), wantEvents: []framework.ClusterEvent{queue.NodeAnnotationChange}, }, { </ins> name:    "only node condition changed", newNode: st.MakeNode().Obj(), oldNode: st.MakeNode().Condition(

Due to limited character space, I've stored additional information in annotations on nodes. My custom scheduling plugins read these annotations to schedule Pods. However, when a Pod fails to be scheduled on a node, I want it to be removed from the Unschedulable queue. This can be achieved by modifying the annotations of the node, allowing the Pod to be rescheduled. Unfortunately, the eventHandler of the scheduler only supports five types of node events, and it does not include the nodeAnnotationsChanged event. Consequently, I am currently unable to trigger rescheduling by changing the annotations of nodes. /sig scheduling Unschedulable pods will be rescheduled after annotations of nodes changed. None No response <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/assign
It's more like a new feature, not bug because it doesn't lead to any bad behavior on the upstream. /remove-kind bug /kind feature
My concern is node annotation is arbitrary, change a node annotation doesn't imply a pod is schedulable. But for other events, like node labels, node taints, they're the constraints we consider in scheduling. They're different, I'm afraid this will lead to invalid scheduling attempts. Who is responsible for change the annotations in you scenario?
This enhancement has no impact on the in-tree plugins / upstream scheduler, right? Only (custom) plugins, that want to reschedule Pods via the node annotation change, will register event to EventsToRegister.
I have a controller capable of modifying node annotations to indicate node's current availability. And my custom plugins need to be aware of these changes.
I guess we can still be impacted when scheduling pod failed because of no fit node rather than failed by the plugin.


Question: wantEvents: []framework.ClusterEvent{queue.NodeTaintChange}, }, { <ins> name:       "only node annotation changed", newNode:    st.MakeNode().Annotation("foo", "bar").Obj(), oldNode:    st.MakeNode().Annotation("foo", "fuz").Obj(), wantEvents: []framework.ClusterEvent{queue.NodeAnnotationChange}, }, { </ins> name:    "only node condition changed", newNode: st.MakeNode().Obj(), oldNode: st.MakeNode().Condition(

see Can we predict whether the pod is schedulable before running into scheduling cycle via the node annotations, then we can leverage the preEnqueue extension point since you already have a external controller.
Thanks for the advice. But I'm afraid it would not be the best solution for us, because doing that outside the scheduling cycle would cause the custom plugins to malfunction in my scenario.
The concerns raised by make sense to me. In my understanding, most in-tree plugins will classify the event as an event.
No. When no fit Pod, UnschedulablePlugins will have plugin(s) rejected the Pod. (e.g., all nodes don't have enough capacity, UnschedulablePlugins has noderesourcefit. all nodes don't satisfy node affinity, UnschedulablePlugins has nodeaffinity) is a rare case like plugins other than PreFilter/Filter returns non-success. I don't think we should care about it.
But, this is a good point, I think we should refactor all plugins that register event with to have a specific Node update event. For example, . It should have with instead of . event with , that should be the last-resort when we don't know which kind of Node update will make Pods schedulable. (I guess no such case at least in the in-tree plugins.)
1) One possibility is Reserve Plugin, I the capability here 2) Another possibility is PreFilter, but not because failed by the plugin, but no fit node exists Have no idea whether we have other places, I guess no. But yes, this only impacts unschedulable pods has no failed plugins.
~I think this is for intended, like ~ ~1. 1) we have a plugin failed by nodeAffinity~ ~2. 2) we add a new node~ ~3. 3) we receive the node add event, but because node not ready, we failed by nodeTaint plugin as ~ 4) node become ready, we get the node update event, but dismatch with nodeAffinity registered event (if we registered with UpdateNodeLabel event)~ ~5. 5) pod will not be moved to the active or backoff queue~ updated below
weigh in for advices as whether this is a good idea to take nodeAnnotations as a new event.


Question: wantEvents: []framework.ClusterEvent{queue.NodeTaintChange}, }, { <ins> name:       "only node annotation changed", newNode:    st.MakeNode().Annotation("foo", "bar").Obj(), oldNode:    st.MakeNode().Annotation("foo", "fuz").Obj(), wantEvents: []framework.ClusterEvent{queue.NodeAnnotationChange}, }, { </ins> name:    "only node condition changed", newNode: st.MakeNode().Obj(), oldNode: st.MakeNode().Condition(

As I know, some plugins will read the embedded prometheus metrics in node annotations for scoring, but not for filtering. At least we should mitigate the impacts.
iv. node become ready, we get the node update event, but dismatch with nodeAffinity registered event (if we registered with UpdateNodeLabel event) (3) is not exact. When we receive the node add event, the scheduler retry to schedule the Pod because the nodeaffinity has Node add event. And it's rejected by the nodetaint plugin. (not node affinity) So, in (4), we get the node update event, it matches with node taint registered event, and the Pod is moved to active/backoffQ (node taint registers node update event. Yes I think we can change node taint's node update event to more specific one(s) though)
As I replied in your PR, we acknowledged that in , and yes let's have your patch. Well, that's a good point. So, when all nodes are filtered out by PreFilterResult, then no failedplugin can be returned. That's a problem. I think we should return the plugin name that returns PreFilterResult with not all Node names in this case (= the plugins that contributes to reducing the candidate Nodes via PreFilterResult). What do you think?
Sorry, the previous one is not right, a detailed one: a. we have a pod failed by nodeAffinity. pod will be placed into the unschedulablePods b. node autoscaler triggered, a new node , emitted a node add event c. called -d. node not ready right now and holds a notReady taint, then failed, pod still stays in the unschedulablePods e. node gets ready, emitted a node update event, but dismatch with the registered event(if we register with in nodeAffinity plugin) f. pod will stay in unschedulabelPods I guess this is the right flow. Anyway, glad to see it be more effect in the future.
If we have no performance problems, I think it's ok to take nodeAnnotations into consideration.
Wouldn't this be solved with proposal on ClusterEventWithHint? If so, I prefer we leave the existing code as-is.
whatever we do here, we wouldn't backport, so I think is the right move forward.
We put many stuff here.


Question: wantEvents: []framework.ClusterEvent{queue.NodeTaintChange}, }, { <ins> name:       "only node annotation changed", newNode:    st.MakeNode().Annotation("foo", "bar").Obj(), oldNode:    st.MakeNode().Annotation("foo", "fuz").Obj(), wantEvents: []framework.ClusterEvent{queue.NodeAnnotationChange}, }, { </ins> name:    "only node condition changed", newNode: st.MakeNode().Obj(), oldNode: st.MakeNode().Condition(

Let me summarize each: Born from from is right. But, that's the problem with preCheck. (Some preCheck depends on some in-tree plugins' logic and it affects badly to other plugins enqueueing ) The preCheck is removed after is completed. After preCheck is removed, will be the correct behavior. So, we can do the optimization that changes node to a specific event. will be fixed in: It's kind of rare case, but I feel we need to have some improvement like Edit: create another issue for this: I'd say (2) and (3) are kind of rare cases. So, the blocker here is (1). (And, (1) is blocked by the removal of preCheck, which is blocked by ) As my conclusion, it's safer to add after (1) is done so that we can make sure the performance won't be affected badly. what do you think?
Instead, can we just keep an event for "node updated", then individual plugins can decide whether a annotations change is worth requeuing or not?
Yes, (1) can be replaced with that idea. But, I'd say changing to a specific is slightly better because the scheduling queue could filter out some Node update events without executing the hint functions.
If rescheduling can be triggered with precise events, that would be great. I haven't revisit since last time, I'll take a look again.
Since we are missing an event for , can we add it? But we also have to modify existing events like so: Because change of such field is also an Update. And in future releases we can get rid of some fine-grained events.
Since we will add hintFuncs for all in-tree plugins, so I think it's ok to add nodeAnnotationsChanged event now, we can filter out unrelated events in hitFuncs. Any other concerns? cc Prefer to keep them as people can register fine-gained events instead a general event.
If by "now" you mean v1.30, then I'm ok with that.


Question: import ( "strconv" <ins> "strings" </ins> "github.com/spf13/pflag"

Because always return names with a prefix like , it cannot be directly used to iterate over all namespaces to execute other commands. I've compiled from source: Reviewing some scripts, I came across a usage of like this: That line fetches namespace names to later run in a loop: That seemed to be a perfect use case for the flag, but it can't be used without extra hacks to get rid of the prefix (FWIW, is invalid). Changing the current output of might not be possible or desirable, for this could impact existing users that rely on the output format. If I'm wrong about the above limitation, than it would make sense to output just the name when and there is a single resource type, while using the ideas introduced in to show the resource type only when there is more than one type in the output, or when is explicitly set. Before: After:
could you help me ping the appropriate team to triage this? Thanks!
Please re-post your question to . We are trying to consolidate the channels to which questions for help/support are posted so that we can improve our efficiency in responding to your requests, and to make it easier for you to find answers to frequently asked questions and how to address common use cases. We regularly see messages posted in multiple forums, with the full response thread only in one place or, worse, spread across multiple forums. Also, the large volume of support issues on github is making it difficult for us to use issues to identify real bugs. The Kubernetes team scans stackoverflow on a regular basis, and will try to ensure your questions don't go unanswered. Before posting a new question, please search stackoverflow for answers to similar questions, and also familiarize yourself with: Again, thanks for using Kubernetes. The Kubernetes Team
perhaps I didn't do a good job at explaining the problem, but this is not a question of how to do something, but a report on a problem with the CLI design.
Sorry about that :-/. I'll try to route to the proper team.
update: console examples to the description.
the -o format is designed for scripting, the use case is just different from yours. You should be able to paste the output of into . Does do what you want? If this is a common use case we could create another -o flag value.


Question: import ( "strconv" <ins> "strings" </ins> "github.com/spf13/pflag"

the use cases I've observed doing code reviews: over all namespaces to get certain resources from that namespace: over all namespaces, then iterate of over resource types that produce logs and fetch logs one by one: Above we can use for listing pods because later we'll pass it to that accept the syntax. We cannot do the same for namespaces, because doesn't like the format.
Alternatively we could be kubectl recognize as valid
I'll take a look on it if it's not taken by anyone yet. CC
Have you started this?
Only investigated due to being out of office since Thursday last week. I can work on it in upcoming week, but I'll understand if it's piority issue and you'll reassign it.
Ready :-)
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
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


Question: } // relist queries the container runtime for list of pods/containers, compare <del> // with the internal pods/containers, and generats events accordingly. </del> <ins> // with the internal pods/containers, and generates events accordingly. </ins> func (g *GenericPLEG) relist() { glog.V(5).Infof("GenericPLEG: Relisting")

Typo fix. Will add the PR links.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
You don't need an issue for typo fix. Please submit the PR directly.
/kind cleanup
sure, let me close it.


Question: }) }) <ins> ginkgo.Describe("CSI Conformance", func() { var pvols e2epv.PVMap var claims e2epv.PVCMap ginkgo.AfterEach(func(ctx context.Context) { framework.Logf("AfterEach: deleting %v PVCs and %v PVs...", len(claims), len(pvols)) errs := e2epv.PVPVCMapCleanup(ctx, c, ns, pvols, claims) if len(errs) > 0 { errmsg := []string{} for _, e := range errs { errmsg = append(errmsg, e.Error()) } framework.Failf("AfterEach: Failed to delete 1 or more PVs/PVCs. Errors: %v", strings.Join(errmsg, "; ")) } }) ginkgo.It("should run through the lifecycle of a PV and a PVC", func(ctx context.Context) { pvClient := c.CoreV1().PersistentVolumes() pvcClient := c.CoreV1().PersistentVolumeClaims(ns) ginkgo.By("Creating initial PV and PVC") // Configure csiDriver defaultFSGroupPolicy := storagev1.ReadWriteOnceWithFSTypeFSGroupPolicy csiDriverLabel := map[string]string{"e2e-test": f.UniqueName} csiDriver := &storagev1.CSIDriver{ ObjectMeta: metav1.ObjectMeta{ Name:   "inline-driver-" + string(uuid.NewUUID()), Labels: csiDriverLabel, }, Spec: storagev1.CSIDriverSpec{ VolumeLifecycleModes: []storagev1.VolumeLifecycleMode{ storagev1.VolumeLifecyclePersistent, }, FSGroupPolicy: &defaultFSGroupPolicy, }, } pvNamePrefix := ns + "-" pvHostPathConfig := e2epv.PersistentVolumeConfig{ NamePrefix: pvNamePrefix, Labels:     volLabel, PVSource: v1.PersistentVolumeSource{ CSI: &v1.CSIPersistentVolumeSource{ Driver:       csiDriver.Name, VolumeHandle: "e2e-conformance", }, }, } numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig) framework.ExpectNoError(err, "Failed to create the requested storage resources") ginkgo.By(fmt.Sprintf("Listing all PVs with the labelSelector: %q", volLabel.AsSelector().String())) pvList, err := pvClient.List(ctx, metav1.ListOptions{LabelSelector: volLabel.AsSelector().String()}) framework.ExpectNoError(err, "Failed to list PVs with the labelSelector: %q", volLabel.AsSelector().String()) gomega.Expect(pvList.Items).To(gomega.HaveLen(1)) initialPV := pvList.Items[0] ginkgo.By(fmt.Sprintf("Listing PVCs in namespace %q", ns)) pvcList, err := pvcClient.List(ctx, metav1.ListOptions{}) framework.ExpectNoError(err, "Failed to list PVCs with the labelSelector: %q", volLabel.AsSelector().String()) gomega.Expect(pvcList.Items).To(gomega.HaveLen(1)) initialPVC := pvcList.Items[0] ginkgo.By(fmt.Sprintf("Patching the PV %q", initialPV.Name)) payload := "{"metadata":{"labels":{"" + initialPV.Name + "":"patched"}}}" patchedPV, err := pvClient.Patch(ctx, initialPV.Name, types.StrategicMergePatchType, []byte(payload), metav1.PatchOptions{}) framework.ExpectNoError(err, "Failed to patch PV %q", initialPV.Name) gomega.Expect(patchedPV.Labels).To(gomega.HaveKeyWithValue(patchedPV.Name, "patched"), "Checking that patched label has been applied") ginkgo.By(fmt.Sprintf("Patching the PVC %q", initialPVC.Name)) payload = "{"metadata":{"labels":{"" + initialPVC.Name + "":"patched"}}}" patchedPVC, err := pvcClient.Patch(ctx, initialPVC.Name, types.StrategicMergePatchType, []byte(payload), metav1.PatchOptions{}) framework.ExpectNoError(err, "Failed to patch PVC %q", initialPVC.Name) gomega.Expect(patchedPVC.Labels).To(gomega.HaveKeyWithValue(patchedPVC.Name, "patched"), "Checking that patched label has been applied") ginkgo.By(fmt.Sprintf("Getting PV %q", patchedPV.Name)) retrievedPV, err := pvClient.Get(ctx, patchedPV.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get PV %q", patchedPV.Name) gomega.Expect(retrievedPV.UID).To(gomega.Equal(patchedPV.UID)) ginkgo.By(fmt.Sprintf("Getting PVC %q", patchedPVC.Name)) retrievedPVC, err := pvcClient.Get(ctx, patchedPVC.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get PVC %q", patchedPVC.Name) gomega.Expect(retrievedPVC.UID).To(gomega.Equal(patchedPVC.UID)) ginkgo.By(fmt.Sprintf("Deleting PVC %q", retrievedPVC.Name)) err = pvcClient.Delete(ctx, retrievedPVC.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err, "Failed to delete PVC %q", retrievedPVC.Name) ginkgo.By(fmt.Sprintf("Confirm deletion of PVC %q", retrievedPVC.Name)) type state struct { PersistentVolumes      []v1.PersistentVolume PersistentVolumeClaims []v1.PersistentVolumeClaim } err = framework.Gomega().Eventually(ctx, framework.HandleRetry(func(ctx context.Context) (*state, error) { pvcList, err := pvcClient.List(ctx, metav1.ListOptions{}) if err != nil { return nil, fmt.Errorf("failed to list pvc: %w", err) } return &state{ PersistentVolumeClaims: pvcList.Items, }, nil })).WithTimeout(30 * time.Second).Should(framework.MakeMatcher(func(s *state) (func() string, error) { if len(s.PersistentVolumeClaims) == 0 { return nil, nil } return func() string { return fmt.Sprintf("Expected pvc to be deleted, found %q", s.PersistentVolumeClaims[0].Name) }, nil })) framework.ExpectNoError(err, "Timeout while waiting to confirm PVC %q deletion", retrievedPVC.Name) ginkgo.By(fmt.Sprintf("Deleting PV %q", retrievedPV.Name)) err = pvClient.Delete(ctx, retrievedPV.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err, "Failed to delete PV %q", retrievedPV.Name) ginkgo.By(fmt.Sprintf("Confirm deletion of PV %q", retrievedPV.Name)) err = framework.Gomega().Eventually(ctx, framework.HandleRetry(func(ctx context.Context) (*state, error) { pvList, err := pvClient.List(ctx, metav1.ListOptions{LabelSelector: volLabel.AsSelector().String()}) if err != nil { return nil, fmt.Errorf("failed to list pv: %w", err) } return &state{ PersistentVolumes: pvList.Items, }, nil })).WithTimeout(30 * time.Second).Should(framework.MakeMatcher(func(s *state) (func() string, error) { if len(s.PersistentVolumes) == 0 { return nil, nil } return func() string { return fmt.Sprintf("Expected pv to be deleted, found %q", s.PersistentVolumes[0].Name) }, nil })) framework.ExpectNoError(err, "Timeout while waiting to confirm PV %q deletion", retrievedPV.Name) ginkgo.By("Recreating another PV & PVC") pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig) framework.ExpectNoError(err, "Failed to create the requested storage resources") var pvName string for key := range pvols { pvName = key } var pvcName string for key := range claims { pvcName = key.Name } ginkgo.By(fmt.Sprintf("Updating the PV %q", pvName)) var updatedPV *v1.PersistentVolume pvSelector := labels.Set{pvName: "updated"}.AsSelector().String() err = retry.RetryOnConflict(retry.DefaultRetry, func() error { pv, err := pvClient.Get(ctx, pvName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get PV %q", pvName) pv.Labels[pvName] = "updated" updatedPV, err = pvClient.Update(ctx, pv, metav1.UpdateOptions{}) return err }) framework.ExpectNoError(err, "failed to update PV %q", pvName) gomega.Expect(updatedPV.Labels).To(gomega.HaveKeyWithValue(updatedPV.Name, "updated"), "Checking that updated label has been applied") ginkgo.By(fmt.Sprintf("Updating the PVC %q", pvcName)) var updatedPVC *v1.PersistentVolumeClaim pvcSelector := labels.Set{pvcName: "updated"}.AsSelector().String() err = retry.RetryOnConflict(retry.DefaultRetry, func() error { pvc, err := pvcClient.Get(ctx, pvcName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get PVC %q", pvcName) pvc.Labels = map[string]string{ pvcName: "updated", } updatedPVC, err = pvcClient.Update(ctx, pvc, metav1.UpdateOptions{}) return err }) framework.ExpectNoError(err, "failed to update PVC %q", pvcName) gomega.Expect(updatedPVC.Labels).To(gomega.HaveKeyWithValue(updatedPVC.Name, "updated"), "Checking that updated label has been applied") ginkgo.By(fmt.Sprintf("Listing PVCs in all namespaces with the labelSelector: %q", pvcSelector)) pvcList, err = c.CoreV1().PersistentVolumeClaims("").List(ctx, metav1.ListOptions{LabelSelector: pvcSelector}) framework.ExpectNoError(err, "Failed to list PVCs in all namespaces with the labelSelector: %q", pvcSelector) gomega.Expect(pvcList.Items).To(gomega.HaveLen(1)) ginkgo.By(fmt.Sprintf("Deleting PVC %q via DeleteCollection", pvcName)) err = pvcClient.DeleteCollection(ctx, metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: pvcSelector}) framework.ExpectNoError(err, "Failed to delete PVC %q", retrievedPVC.Name) ginkgo.By(fmt.Sprintf("Confirm deletion of PVC %q", pvcName)) err = framework.Gomega().Eventually(ctx, framework.HandleRetry(func(ctx context.Context) (*state, error) { pvcList, err := pvcClient.List(ctx, metav1.ListOptions{LabelSelector: pvcSelector}) if err != nil { return nil, fmt.Errorf("failed to list pvc: %w", err) } return &state{ PersistentVolumeClaims: pvcList.Items, }, nil })).WithTimeout(30 * time.Second).Should(framework.MakeMatcher(func(s *state) (func() string, error) { if len(s.PersistentVolumeClaims) == 0 { return nil, nil } return func() string { return fmt.Sprintf("Expected pvc to be deleted, found %q", s.PersistentVolumeClaims[0].Name) }, nil })) framework.ExpectNoError(err, "Timeout while waiting to confirm PVC %q deletion", pvcName) ginkgo.By(fmt.Sprintf("Deleting PV %q via DeleteCollection", pvName)) err = pvClient.DeleteCollection(ctx, metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: pvSelector}) framework.ExpectNoError(err, "Failed to delete PV %q", retrievedPVC.Name) ginkgo.By(fmt.Sprintf("Confirm deletion of PV %q", pvName)) err = framework.Gomega().Eventually(ctx, framework.HandleRetry(func(ctx context.Context) (*state, error) { pvList, err := pvClient.List(ctx, metav1.ListOptions{LabelSelector: pvSelector}) if err != nil { return nil, fmt.Errorf("failed to list pv: %w", err) } return &state{ PersistentVolumes: pvList.Items, }, nil })).WithTimeout(30 * time.Second).Should(framework.MakeMatcher(func(s *state) (func() string, error) { if len(s.PersistentVolumes) == 0 { return nil, nil } return func() string { return fmt.Sprintf("Expected pv to be deleted, found %q", s.PersistentVolumes[0].Name) }, nil })) framework.ExpectNoError(err, "Timeout while waiting to confirm PV %q deletion", retrievedPV.Name) }) }) </ins> // testsuites/multivolume tests can now run with windows nodes // This test is not compatible with windows because the default StorageClass // doesn't have the ntfs parameter, we can't change the status of the cluster

[X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC 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 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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: ds.Spec.UpdateStrategy = *strategy setDaemonSetToleration(ds, noScheduleTolerations) manager, podControl, _ := newTestController(ds) <del> node := newNode("untainted", nil) manager.nodeStore.Add(node) </del> <ins> addNodes(manager.nodeStore, 0, 1, nil) </ins> manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0, 0) } } <ins> // DaemonSet should launch a pod on a not ready node with taint notReady:NoExecute. func TestDaemonSetRespectsTermination(t *testing.T) { for _, strategy := range updateStrategies() { ds := newDaemonSet("foo") ds.Spec.UpdateStrategy = *strategy manager, podControl, _ := newTestController(ds) addNodes(manager.nodeStore, 0, 1, simpleNodeLabel) pod := newPod(fmt.Sprintf("%s-", "node-0"), "node-0", simpleDaemonSetLabel, ds) dt := metav1.Now() pod.DeletionTimestamp = &dt manager.podStore.Add(pod) manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 0, 0, 0) } } </ins> func setNodeTaint(node *v1.Node, taints []v1.Taint) { node.Spec.Taints = taints }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The DaemonSet controller will schedule a pod on a node when the old pod is still in Terminating state. This breaks the expectation that only one pod will be running at a time per node. What you expected to happen: The DaemonSet controller should not let two pods running at the same time on the same node. How to reproduce it (as minimally and precisely as possible): Create a DaemonSet. Set terminationGracePeriodSeconds to be relatively long. Kill a pod. Watch a new pod start on the same node when the old pod is still terminating. Anything else we need to know?: Seems this behavior was introduced in Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
/cc
cc
cc: I think the expected behavior is correct, the terminating pod could be performing an important step such as 'removing a lock' or 'cleanup' etc., we should allow that to gracefully die before creating a new one. IMHO we should revoke to old behavior, but why did we need this new behavior in the first place? That is not clear to me from the PR and Issue.
We don't currently guarantee at least or at most one scheduling for DaemonSet. Both behaviors are under consideration via issue and in the future work section of the . The reason for is to "Make sure that controllers are not adopting children that are marked for deletion" (). This is necessary for GC to work properly.
Well the behavior may be technically undefined, but can I request that in the future changes like this be mentioned in the release notes?
Yes, certainly.


Question: ds.Spec.UpdateStrategy = *strategy setDaemonSetToleration(ds, noScheduleTolerations) manager, podControl, _ := newTestController(ds) <del> node := newNode("untainted", nil) manager.nodeStore.Add(node) </del> <ins> addNodes(manager.nodeStore, 0, 1, nil) </ins> manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0, 0) } } <ins> // DaemonSet should launch a pod on a not ready node with taint notReady:NoExecute. func TestDaemonSetRespectsTermination(t *testing.T) { for _, strategy := range updateStrategies() { ds := newDaemonSet("foo") ds.Spec.UpdateStrategy = *strategy manager, podControl, _ := newTestController(ds) addNodes(manager.nodeStore, 0, 1, simpleNodeLabel) pod := newPod(fmt.Sprintf("%s-", "node-0"), "node-0", simpleDaemonSetLabel, ds) dt := metav1.Now() pod.DeletionTimestamp = &dt manager.podStore.Add(pod) manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 0, 0, 0) } } </ins> func setNodeTaint(node *v1.Node, taints []v1.Taint) { node.Spec.Taints = taints }

Also "The DaemonSet controller should not let two pods running at the same time on the same node." is not necessarily the same thing as respecting termination prior to launching a new Pod. The former implies a more strict requirement than the latter. I think we should consider at least attempting to wait for a terminating Pod to be deleted prior to creating another Pod on the Node for same DaemonSet as default behavior.
will something like work then?


Question: func WaitTimeoutForPodReadyInNamespace(c clientset.Interface, podName, namespace string, timeout time.Duration) error { return WaitForPodCondition(c, namespace, podName, "running and ready", timeout, func(pod *v1.Pod) (bool, error) { switch pod.Status.Phase { <del> case v1.PodFailed, v1.PodSucceeded: </del> <ins> case v1.PodFailed: e2elog.Logf("The phase of Pod %s is %s which is unexpected, pod status: %#v", pod.Name, pod.Status.Phase, pod.Status) return false, errPodFailed case v1.PodSucceeded: </ins> e2elog.Logf("The phase of Pod %s is %s which is unexpected, pod status: %#v", pod.Name, pod.Status.Phase, pod.Status) return false, errPodCompleted case v1.PodRunning:

treats any error returned by the condition as terminal, but silently ignores any errors that aren't returned along with . We should change WaitForPodCondition to behave like . /sig testing /area e2e-test-framework
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The 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]:
/remove-lifecycle stale
Was there any reason why you instead of doing this right away? I fully agree with this issue, we should abort early. I just found the TODO because I have a failing test that ran longer than expected after a final pod failure and that made me check out why it didn't abort quicker :grin:


Question: expectedError: `[0].valueFrom: Invalid value: "": may not have more than one field specified at a time`, }, { <ins> name: "valueFrom.secretKeyRef.name invalid", envs: []api.EnvVar{{ Name: "abc", ValueFrom: &api.EnvVarSource{ SecretKeyRef: &api.SecretKeySelector{ LocalObjectReference: api.LocalObjectReference{ Name: "$%^&*#", }, Key: "a-key", }, }, }}, }, { name: "valueFrom.configMapKeyRef.name invalid", envs: []api.EnvVar{{ Name: "abc", ValueFrom: &api.EnvVarSource{ ConfigMapKeyRef: &api.ConfigMapKeySelector{ LocalObjectReference: api.LocalObjectReference{ Name: "$%^&*#", }, Key: "some-key", }, }, }}, }, { </ins> name: "missing FieldPath on ObjectFieldSelector", envs: []api.EnvVar{{ Name: "abc",

Scenario: Expected results: pod would not be created as [0] is invalid Actual results: pod is created. Turns out we are not doing any validation of envFrom in container spec today.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
I don't know that we can tighten without failing pods.
The validation code exists, but there was no wiring done from validateContainers.
Pods fail on kubelet already. So those pods were not doing much already. We had a BZ on this.
Fail how - fail to even start, or fail to get the input?


Question: } func Test_RaceTerminateRSList(t *testing.T) { <del> ipvs := &utilipvstest.FakeIPVS{} </del> <ins> ipvs := utilipvstest.NewFake() </ins> gracefulTerminationManager := NewGracefulTerminationManager(ipvs) <ins> // run in parallel to cause the race </ins> go func() { for i := 1; i <= 10; i++ { <del> for j := 1; i <= 100; j++ { gracefulTerminationManager.rsList.add(makeListItem(i, j)) </del> <ins> for j := 1; j <= 100; j++ { item := makeListItem(i, j) gracefulTerminationManager.rsList.add(item) </ins> } } }() <del> if !gracefulTerminationManager.rsList.flushList(gracefulTerminationManager.deleteRsFunc) { </del> <ins> // wait until the list has some elements for gracefulTerminationManager.rsList.len() < 20 { } // fake the handler to avoid the check against the IPVS virtual servers fakeHandler := func(rsToDelete *listItem) (bool, error) { return true, nil } if !gracefulTerminationManager.rsList.flushList(fakeHandler) { </ins> t.Error("failed to flush entries") } }

pull-kubernetes-unit ~1 day since merging of Test introduced in /sig network
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
/cc
ahhhg let me fix it
oh, I will take a look.


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected character device, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected character device, got unexpected file: %s", i, tc.name, path) } if oftc.IsSocket() {

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: This feature is lacking coverage, especially for containerized kubelet environments.
/assign since I'm the owner of this feature.
And just fixes a bug for containerized kubelet when the mount file is an empty file.
Are we going to enable these tests in v1.11? We're getting code freeze soon.
There is a local containerized cluster pull and CI job that we can probably leverage. Right now it only runs conformance tests, we may be able to add new suites to enable other tests. Cc who can point us to the owner for the containerized testing effort
yes, seems to be holding up pretty well - https://k8s-,%20master%20(dev)
In I made pull-kubernetes-local-e2e-containerized to run also all test with string. I'm enabling some tests (subpath!) in , feel free to suggest more tests.
Ref
IIUC, the default host path type is . And when host path type is , we expect container runtime to create the host path if it doesn't exist (docker is doing that today). Is that true? If that is, we should revert part of , because container runtime should still create host path if it does not exist. /cc I tried to enforce , and got a lot of errors , e.g.:
Correct. This is mainly for backwards compatibility.
I see. If so, I'll remove the CRI definition "If the hostPath doesn't exist (e.g. hostPath volume), runtimes should report errors". Thanks!
SGTM. Refer to .
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 will help fix this.
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.


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected character device, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected character device, got unexpected file: %s", i, tc.name, path) } if oftc.IsSocket() {

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
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-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 .


Question: if oftc.IsDir() { t.Errorf("[%d: %q] expected character device, got unexpected folder: %s", i, tc.name, path) } <del> if !oftc.IsFile() { </del> <ins> if oftc.IsFile() { </ins> t.Errorf("[%d: %q] expected character device, got unexpected file: %s", i, tc.name, path) } if oftc.IsSocket() {

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


Question: switch pod.Status.Phase { case v1.PodRunning: return true, nil <del> case v1.PodFailed, v1.PodSucceeded: </del> <ins> case v1.PodFailed: return false, errPodFailed case v1.PodSucceeded: </ins> return false, errPodCompleted } return false, nil


Question: "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/intstr:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//vendor/k8s.io/client-go/informers:go_default_library", "//vendor/k8s.io/client-go/kubernetes:go_default_library",

/kind bug What happened: On a large cluster with enough pods, endpoints take as long as 10 minutes to show up after their associated pods and service are created. We believe that this is because every pod change results in an update of the addresses within the endpoint since they refer to a pod via a whose changes every time a pod change is observed. All these non-update updates eventually overwhelm the endpoint controller's queue rate limit and the queue starts to grow. While an increase in the queue's rate limit can alleviate the problem, an admin can keep a much lower limit if the non-update updates are dropped rather than processed. What you expected to happen: When a pod related to an endpoint is updated, I would expect the endpoint to update only if there is a change in the pod that relates to the endpoint, such as a change in the pod's IP address. How to reproduce it (as minimally and precisely as possible): a pod and associated service: the endpoint for changes: the watch running, and in another session, edit a pod to add a label: Then add another label on the line after the label, such as that the watched endpoint changed despite there not being any meaningful change to the fields the endpoint cares about. Anything else we need to know?: The PR addresses this issue. Environment: Kubernetes version (use ):
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig scalability
what ever happened with the effort to move leases off of Endpoints?


Question: } } <ins> func TestBigDec(t *testing.T) { table := []struct { got    infDecAmount expect string }{ {bigDec(big.NewInt(1), 0), "1"}, {bigDec(big.NewInt(1), 1), "10"}, {bigDec(big.NewInt(5), 2), "500"}, {bigDec(big.NewInt(8), 3), "8000"}, {bigDec(big.NewInt(2), 0), "2"}, {bigDec(big.NewInt(1), -1), "0.1"}, {bigDec(big.NewInt(3), -2), "0.03"}, {bigDec(big.NewInt(4), -3), "0.004"}, {bigDec(big.NewInt(0).Add(bigMostPositive, big.NewInt(1)), 0), "9223372036854775808"}, {bigDec(big.NewInt(0).Add(bigMostPositive, big.NewInt(1)), 1), "92233720368547758080"}, {bigDec(big.NewInt(0).Add(bigMostPositive, big.NewInt(1)), 2), "922337203685477580800"}, {bigDec(big.NewInt(0).Add(bigMostPositive, big.NewInt(1)), -1), "922337203685477580.8"}, {bigDec(big.NewInt(0).Add(bigMostPositive, big.NewInt(1)), -2), "92233720368547758.08"}, {bigDec(big.NewInt(0).Sub(bigMostNegative, big.NewInt(1)), 0), "-9223372036854775809"}, {bigDec(big.NewInt(0).Sub(bigMostNegative, big.NewInt(1)), 1), "-92233720368547758090"}, {bigDec(big.NewInt(0).Sub(bigMostNegative, big.NewInt(1)), 2), "-922337203685477580900"}, {bigDec(big.NewInt(0).Sub(bigMostNegative, big.NewInt(1)), -1), "-922337203685477580.9"}, {bigDec(big.NewInt(0).Sub(bigMostNegative, big.NewInt(1)), -2), "-92233720368547758.09"}, } for _, item := range table { if e, a := item.expect, item.got.Dec.String(); e != a { t.Errorf("expected %v, got %v", e, a) } } } </ins> // TestQuantityParseZero ensures that when a 0 quantity is passed, its string value is 0 func TestQuantityParseZero(t *testing.T) { zero := MustParse("0")

I'd like to add a multiplication method for the resource.Quantity. Currently, the resource package provides helper methods to calculate Quantity, such as and : Batch workloads often replicate the same PodTemplate, and controllers calculate the resources needed for all containers. In that case, It is inconvenient to call the function as many times as podTemplate, so I would like to create a helper function for multiplication.
/cc /sig api-machinary /wg batch
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /cc /sig api-machinary /wg batch </details
/sig api-machinery /wg batch
Do you have an example of usage for these utilities? Just curious?
/triage accepted
Sorry for the late response. Taking k-sigs/kueue as an example, I assumed the below: It helps the controllers for batch workloads such as k-sigs/kueue, k-sigs/jobset, kubeflow/mpi-operator, and kubeflow/training-operator. I'm thinking of implementing this function once the code freeze term is finished.
/assign
Hi, may i take this up?
I took this one, and working on this now.


Question: podClient := e2epod.NewPodClient(f) terminationGracePeriod := int64(30) script := ` <del> _term() { </del> <ins> _term() { </ins> rm -f /tmp/ready rm -f /tmp/liveness sleep 20

Tests in are using image for gRPC probe tests: should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe We should use image for these tests as it is much smaller size. /sig node /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue KEP:
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Tests in are using image for gRPC probe tests: /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi can I work on this issue? I'm new to Kubernetes and want to contribute!
Should I change to in this file?
Yes.


Question: podClient := e2epod.NewPodClient(f) terminationGracePeriod := int64(30) script := ` <del> _term() { </del> <ins> _term() { </ins> rm -f /tmp/ready rm -f /tmp/liveness sleep 20

Also pass proper parameters to agnhost to enable gRPC endpoint, change ports, and run tests to ensure that this worked.
Thanks for your reply! Will let you know if I have more questions as I work
/assign
/assign


Question: } // Build a scheduler config from the provided algorithm source. <del> schedulerConfig, err := NewSchedulerConfig(c) </del> <ins> schedulerConfig, err := NewSchedulerConfig(cc) </ins> if err != nil { return err }

PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: In the function creates a object and populates the field with an anonymous function. At the end of that function, is called, which contains the rest of our startup logic. Rather than split this across two functions, we should put all the startup logic in one named function called (not ) so that constructing the object is much more plain. /sig scheduling /kind cleanup /help /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 : PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: Rather than split this across two functions, we should put all the startup logic in one named function called (not ) so that constructing the object is much more plain. /kind cleanup /help /good-first-issue </details
I'll pick this up! /assign


Question: return fmt.Errorf("Loadbalancer %s does not exist", loadBalancerName) } <del> // Set of member (addresses) that _should_ exist addrs := map[string]bool{} for _, host := range hosts { addr, err := getAddressByName(lbaas.compute, host) </del> <ins> // Get all listeners for this loadbalancer, by "port key". type portKey struct { Protocol string Port     int } lbListeners := make(map[portKey]listeners.Listener) err = listeners.List(lbaas.network, listeners.ListOpts{LoadbalancerID: loadbalancer.ID}).EachPage(func(page pagination.Page) (bool, error) { listenersList, err := listeners.ExtractListeners(page) </ins> if err != nil { <del> return err </del> <ins> return false, err </ins> } <del> addrs[addr] = true </del> <ins> for _, l := range listenersList { key := portKey{Protocol: l.Protocol, Port: l.ProtocolPort} lbListeners[key] = l } return true, nil }) if err != nil { return err </ins> } <del> // Iterate over members in each pool that _do_ exist var poolID string </del> <ins> // Get all pools for this loadbalancer, by listener ID. lbPools := make(map[string]v2_pools.Pool) </ins> err = v2_pools.List(lbaas.network, v2_pools.ListOpts{LoadbalancerID: loadbalancer.ID}).EachPage(func(page pagination.Page) (bool, error) { poolsList, err := v2_pools.ExtractPools(page) if err != nil { return false, err } <del> for _, pool := range poolsList { poolID = pool.ID err := v2_pools.ListAssociateMembers(lbaas.network, poolID, v2_pools.MemberListOpts{}).EachPage(func(page pagination.Page) (bool, error) { membersList, err := v2_pools.ExtractMembers(page) if err != nil { return false, err } for _, member := range membersList { if _, found := addrs[member.Address]; found { // Member already exists, remove from update list delete(addrs, member.Address) } else { // Member needs to be deleted err = v2_pools.DeleteMember(lbaas.network, poolID, member.ID).ExtractErr() if err != nil { return false, err } waitLoadbalancerActiveProvisioningStatus(lbaas.network, loadbalancer.ID) } } return true, nil }) if err != nil { return false, err </del> <ins> for _, p := range poolsList { for _, l := range p.Listeners { lbPools[l.ID] = p </ins> } } return true, nil

LBaaS implementation (v1 or v2) will not support services that require to load balancer more than one port.
Fixed for LBaaS v2 by I suspect LBaaS v1 can't support multiple ports (not sure if reusing the VIP across multiple loadbalancers is a universally supported thing). I also believe LBaaS v1 is also mostly gone in favour of v2 in deployments so trying to address this in v1 is extremely low priority unless someone steps forward to ask for it. So: I think we can close this bug now, but I lack the powers to do that directly.
thank you for the update.


Question: type mockedRouter struct { destinationHost string <ins> err             error </ins> } func (r *mockedRouter) ResolveEndpoint(namespace, name string) (*url.URL, error) { <del> return &url.URL{ Scheme: "https", Host:   r.destinationHost, }, nil </del> <ins> return &url.URL{Scheme: "https", Host: r.destinationHost}, r.err </ins> } func TestProxyHandler(t *testing.T) {

https://k8s- https://k8s- https://k8s- https://k8s- https://k8s- ... A lot of them /cc
/assign
Still see this failure after is merged, although less frequently: https://k8s- https://k8s- Reopen.
Looks like the client doesn't differentiate between 500 and 503 here: It should. Will open a fix shortly
opened
fix merged, will monitor https://k8s-
Thanks! :)
haven't seen this in the 12 hours since the fix merged, was seeing it every 2-3 hours before. /close


Question: <ins> /* Copyright 2017 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 clientcmd // transformingStringValue implements pflag.Value to store string values, // allowing transforming them while being set type transformingStringValue struct { target      *string transformer func(string) (string, error) } func newTransformingStringValue(val string, target *string, transformer func(string) (string, error)) *transformingStringValue { *target = val return &transformingStringValue{ target:      target, transformer: transformer, } } func (t *transformingStringValue) Set(val string) error { val, err := t.transformer(val) if err != nil { return err } *t.target = val return nil } func (t *transformingStringValue) Type() string { return "string" } func (t *transformingStringValue) String() string { return string(*t.target) } </ins>

Because always return names with a prefix like , it cannot be directly used to iterate over all namespaces to execute other commands. I've compiled from source: Reviewing some scripts, I came across a usage of like this: That line fetches namespace names to later run in a loop: That seemed to be a perfect use case for the flag, but it can't be used without extra hacks to get rid of the prefix (FWIW, is invalid). Changing the current output of might not be possible or desirable, for this could impact existing users that rely on the output format. If I'm wrong about the above limitation, than it would make sense to output just the name when and there is a single resource type, while using the ideas introduced in to show the resource type only when there is more than one type in the output, or when is explicitly set. Before: After:
could you help me ping the appropriate team to triage this? Thanks!
Please re-post your question to . We are trying to consolidate the channels to which questions for help/support are posted so that we can improve our efficiency in responding to your requests, and to make it easier for you to find answers to frequently asked questions and how to address common use cases. We regularly see messages posted in multiple forums, with the full response thread only in one place or, worse, spread across multiple forums. Also, the large volume of support issues on github is making it difficult for us to use issues to identify real bugs. The Kubernetes team scans stackoverflow on a regular basis, and will try to ensure your questions don't go unanswered. Before posting a new question, please search stackoverflow for answers to similar questions, and also familiarize yourself with: Again, thanks for using Kubernetes. The Kubernetes Team
perhaps I didn't do a good job at explaining the problem, but this is not a question of how to do something, but a report on a problem with the CLI design.
Sorry about that :-/. I'll try to route to the proper team.
update: console examples to the description.
the -o format is designed for scripting, the use case is just different from yours. You should be able to paste the output of into . Does do what you want? If this is a common use case we could create another -o flag value.


Question: <ins> /* Copyright 2017 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 clientcmd // transformingStringValue implements pflag.Value to store string values, // allowing transforming them while being set type transformingStringValue struct { target      *string transformer func(string) (string, error) } func newTransformingStringValue(val string, target *string, transformer func(string) (string, error)) *transformingStringValue { *target = val return &transformingStringValue{ target:      target, transformer: transformer, } } func (t *transformingStringValue) Set(val string) error { val, err := t.transformer(val) if err != nil { return err } *t.target = val return nil } func (t *transformingStringValue) Type() string { return "string" } func (t *transformingStringValue) String() string { return string(*t.target) } </ins>

the use cases I've observed doing code reviews: over all namespaces to get certain resources from that namespace: over all namespaces, then iterate of over resource types that produce logs and fetch logs one by one: Above we can use for listing pods because later we'll pass it to that accept the syntax. We cannot do the same for namespaces, because doesn't like the format.
Alternatively we could be kubectl recognize as valid
I'll take a look on it if it's not taken by anyone yet. CC
Have you started this?
Only investigated due to being out of office since Thursday last week. I can work on it in upcoming week, but I'll understand if it's piority issue and you'll reassign it.
Ready :-)
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
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


Question: containerManager:  cm.NewContainerManager(cgroupsName, client), checkpointHandler: checkpointHandler, } <ins> // check docker version compatibility. if err = ds.checkVersionCompatibility(); err != nil { return nil, err } // create streaming server if configured. </ins> if streamingConfig != nil { var err error ds.streamingServer, err = streaming.NewServer(*streamingConfig, ds.streamingRuntime)

This mirrors what we do for dockertools. /cc
Is there a maintained list of docker versions supported ?
Is this the proper place to check
That was the proper place to check, but those code are being deprecated. The new one doesn't have a check yet, and that's what this issue is for.
Let me add the check.
/assign


Question: expectNoError(ScaleRC(config.Client, config.Namespace, config.Name, newSize, true), fmt.Sprintf("scaling rc %s for the first time", config.Name)) selector := labels.SelectorFromSet(labels.Set(map[string]string{"name": config.Name})) <del> options := unversioned.ListOptions{LabelSelector: unversioned.LabelSelector{selector}} </del> <ins> options := unversioned.ListOptions{ LabelSelector:   unversioned.LabelSelector{selector}, ResourceVersion: "0", } </ins> _, err := config.Client.Pods(config.Namespace).List(options) expectNoError(err, fmt.Sprintf("listing pods from rc %v", config.Name)) }

The label(s) cannot be applied. These labels are supported: <detailsIn response to : This one is trying to use with a generator to create an rc. This was deprecated and now is removed, so the test is failing now. /label sig/undefined 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
/label failing-test
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label failing-test 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
/kind failing-test
At first I thought this was because generators were removed from . That still might be the cause of this, but I'm not 100% sure off-hand.
/sig cli
/assign
Funny thing about this is if you look in the build logs it is not immediately obvious that it is caused by generators being removed from because actually has sort of an unexpected behavior, where it tells you it is deprecated and gives you a pod instead... For example: Output:
/reopen should fix this is one of the affected jobs
Reopened this issue. <detailsIn response to : /reopen should fix 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
Since it's been a few weeks, I wanted to provide an update on this. I'm still waiting to confirm this is resolved by It looks like it is still running the old tests not marked as . Since 1.17.9 was released 14 days ago, and k8s-ci-robot only merged the PR 13 days ago, I'm guessing we need to wait until there is a 1.17.10 to see it skip the deprecated tests.
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.