Question: framework.ExpectNoError(err) beforeKC = kc } <ins> // show hidden metrics for release 1.22 beforeKC = updateShowHiddenMetricsForVersion(beforeKC, "1.22") </ins> // reset the node's assigned/active/last-known-good config by setting the source to nil, // so each test starts from a clean-slate (&nodeConfigTestCase{

This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
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
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon


Question: return &azureToken{ token:       *token, <ins> environment: ts.environment.Name, </ins> clientID:    ts.clientID, tenantID:    ts.tenantID, apiserverID: ts.apiserverID,

What happened: AAD support in kubectl does not work for sovereign cloud The 'environment' parameter was introduced to support sovereign cloud, but it works in first round. The 'environment' value is not persisted, so follow-up requests will fail. What you expected to happen: 'environment' parameter persisted in kubectl config file. How to reproduce it (as minimally and precisely as possible): Use kubectl to connect to Azure sovereign cloud, make the token expire, and do auth. Anything else we need to know?: Environment: Kubernetes version (use ): 1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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


Question: RuntimeCgroupsName    string SystemCgroupsName     string KubeletCgroupsName    string <ins> KubeletOOMScoreAdj    int32 </ins> ContainerRuntime      string CgroupsPerQOS         bool CgroupRoot            string

runs in a container. Talos sets OOM score to -450 for the kubelet container and passes in the kubelet config. End result is that OOM score adj is -999 though. should have configured OOM score . Source code analysis. First, OOM score is set correctly from the config (flags): But then, in container manager, OOM score is reset to -999 via the following: This function should skip action if the PID is not running on the host: But the function looks to be confusing: When kubelet runs in a container with PID namespace shared with the host, kubelet's PID namespace will be equal to PID 1 namespace. If kubelet runs in a container with unshared PID namespace, kubelet's PID is 1 and its PID namespace is identical to PID 1 namespace. So how this function can return ever? Moreover, function is always setting OOM score to a hardcoded constant -999 ignoring configuation (). No response <details, reproduced with 1.22. </details<details</details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
/assign
I don't think this method needs to change... I have make a draft PR for the default value to use the flag if present, but I would like more time to add some testing. Maybe you can have a look: ?
Thanks, this PR looks good to me, as it's going to set the OOM score to the configured value. And in our case kubelet runs in a container (not on the host, with proper OOM score via OCI spec), so this code should be even skipped, not sure how this can be addressed.
neither do I...
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


Question: } } <ins> func TestEvictPodsToFreeRequestsWithError(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.ExperimentalCriticalPodAnnotation, true)() type testRun struct { testName              string inputPods             []*v1.Pod insufficientResources admissionRequirementList expectErr             bool expectedOutput        []*v1.Pod } podProvider := newFakePodProvider() podKiller := newFakePodKiller(true) criticalPodAdmissionHandler := getTestCriticalPodAdmissionHandler(podProvider, podKiller) allPods := getTestPods() runs := []testRun{ { testName: "multiple pods eviction error", inputPods: []*v1.Pod{ allPods[critical], allPods[bestEffort], allPods[burstable], allPods[highRequestBurstable], allPods[guaranteed], allPods[highRequestGuaranteed]}, insufficientResources: getAdmissionRequirementList(0, 550, 0), expectErr:             false, expectedOutput:        nil, }, } for _, r := range runs { podProvider.setPods(r.inputPods) outErr := criticalPodAdmissionHandler.evictPodsToFreeRequests(allPods[critical], r.insufficientResources) outputPods := podKiller.getKilledPods() if !r.expectErr && outErr != nil { t.Errorf("evictPodsToFreeRequests returned an unexpected error during the %s test.  Err: %v", r.testName, outErr) } else if r.expectErr && outErr == nil { t.Errorf("evictPodsToFreeRequests expected an error but returned a successful output=%v during the %s test.", outputPods, r.testName) } else if !podListEqual(r.expectedOutput, outputPods) { t.Errorf("evictPodsToFreeRequests expected %v but got %v during the %s test.", r.expectedOutput, outputPods, r.testName) } podKiller.clear() } } </ins> func TestEvictPodsToFreeRequests(t *testing.T) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.ExperimentalCriticalPodAnnotation, true)() type testRun struct {

What happened: Kops runs from a pod manifest stored on the node, having the annotation. We've experienced the case where the cluster autoscaler turned on a new node and, once the node has been to the cluster, application pods have been admitted before . Once it was the turn of , all system resources were utilized, so the pod has not been regularly admitted. However, since it's a critical pod, the executed the , which has tried to kill () a pod whose container wasn't started yet (it was downloading the Docker image), which has caused to timeout and return the error . The admission of failed with the following error: The pod execution has not been retried, so we've got a node without running and its networking broken. What you expected to happen: The should be eventually admitted. Anything else we need to know?: A minimal log extraction for comprehension: From the "Failed to admit pod" log I have been able to trace back the core code involved: () Logs: "Failed to admit pod [POD] - [ERROR]" () Error message: "preemption: pod [POD] failed to evict [ERROR]" () -() Error message: "timeout waiting to kill pod" Environment: Kubernetes version: Cloud provider: AWS OS: ubuntu 16.04.6 LTS (Xenial Xerus) Kernel: Install tools: kops Network plugin and version: kubenet
/sig node
I think the following change may alleviate the situation you encountered:
Thanks for your reply. To my understanding, when the is called it will return the minimum set of pods required to free up resources, so even if only 1 pod eviction fails it's likely that at the end of the the will not have enough resources anyway to admit the critical pod. In your opinion / experience: be an option introducing retries in the in case the eviction of 1 pod fails? yes, do you have any suggestion of a similar design adopted somewhere else in the ?
Looking at getPodsToPreempt, I am not sure it returns the minimum set of Pods. For , retrying may not help much since the pod to be killed may not respond to the subsequent kill command.
Sorry to reiterate on this, but I double checked the code and - if I'm not missing anything - returns the minimum set of pods.

Let's look at logic: pods by QOS class using that the total sum of evictable pods resources is enough to satify the requirements (resources to evict for the critical pod) the list of pods to evict, as the merge of three sublists: : the minimum set of pods to evict assuming we've already evicted all and all : the minimum set of pods to evict assuming we've already evicted all and the required : the minimum set of pods to evict to satify the requirements left Am I missing anything? A possible different approach to solve the issue is to refactor to return all input pods sorted by "should be evicted first". Then iterates over the full sorted list of potential pods to evict until the requirements are not satisfied (skipping to subtract pod resources from requirements if a pod fails on ) and breaking the loop as soon as the requirements are satisfied. What's your take on this? /cc who originally implemented this
w.r.t. approach outlined above, it makes sense.
Whether this evicts the "minimum set" depends on how you define the "minimum set". At the time this was implemented (k8s v1.5.0 IIRC), we didn't have PodPriority, so we used QoS to mirror the kubelet's eviction algorithm. It should probably prioritize low-priority pods for eviction today given the recent changes to the eviction algorithm to incorporate PodPriority. The current approach minimizes the eviction of guaranteed pods, and prioritizes evicting few larger pods over many smaller ones. Since eviction marks the evicted pod as failed, it should suffice to just admit the pod regardless of what is returned by the evictPod function. In future syncPod loops, the kubelet will retry the pod deletion steps that it was stuck on. It would eliminate this class of bugs entirely, which was the purpose of the feature in the first place.
See if the following aligns with your suggestion:
Something like that, yeah. I'm not sure the "Failed to admit pod" log warning is still required, but we can iron those things out during code review.
Doing like this it means we do always admit pods, while we should do it only for critical pods, correct?
Please see this The change is for critical pod(s).


Question: testAccount = "test-service-account" ) <ins> func prepareVolumeInfoFile(mountPath string, plug *csiPlugin, specVolumeName, volumeID, driverName, lifecycleMode string) error { nodeName := string(plug.host.GetNodeName()) volData := map[string]string{ volDataKey.specVolID:           specVolumeName, volDataKey.volHandle:           volumeID, volDataKey.driverName:          driverName, volDataKey.nodeName:            nodeName, volDataKey.attachmentID:        getAttachmentName(volumeID, driverName, nodeName), volDataKey.volumeLifecycleMode: lifecycleMode, } if err := os.MkdirAll(mountPath, 0755); err != nil { return fmt.Errorf("failed to create dir for volume info file: %s", err) } if err := saveVolumeData(mountPath, volDataFileName, volData); err != nil { return fmt.Errorf("failed to save volume info file: %s", err) } return nil } </ins> func TestMounterGetPath(t *testing.T) { plug, tmpDir := newTestPlugin(t, nil) defer os.RemoveAll(tmpDir)

Instantiating the interface causes the creation of pod local volume directory and json data file and not - This causes a problem where is failed (and as a result never gets called) then those pod local volume directories will never be cleaned up. /sig storage cc
Looks like is the PR that introduced this change and moved data file creation calls 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
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/repen /remove-lifecycle stale
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
/remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue.

<detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen 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


Question: "testing" ) <del> func TestLoopbackHostPort(t *testing.T) { </del> <ins> func TestLoopbackHostPortIPv4(t *testing.T) { _, ipv6only, err := isIPv6LoopbackSupported() if err != nil { t.Fatalf("fail to enumerate network interface, %s", err) } if ipv6only { t.Fatalf("no ipv4 loopback interface") } </ins> host, port, err := LoopbackHostPort("1.2.3.4:443") if err != nil { t.Fatalf("unexpected error: %v", err)

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: LoopbackHostPort code is calling the which depends on the machine on which this test is running. Especially in this particular testase it looks for the ipv6 ip address which does not exist because the machine is not configured for ipv6. Because of the LoopbackHostPort function bahaves based on the interfaces configured, test will fail if machine is not really configured with ipv6. Need to rewrite the testcase to handle such situation. What you expected to happen: Testcase should pass
/sig network
/cc
/triage unresolved I am a bot run by
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/remove-triage unresolved


Question: } if unmanaged { if az.ipv6DualStackEnabled { <del> //TODO (khenidak) add support for unmanaged nodes when the feature reaches  beta </del> <ins> //TODO (khenidak) add support for unmanaged nodes when the feature reaches beta </ins> return fmt.Errorf("unmanaged nodes are not supported in dual stack mode") } klog.V(2).Infof("CreateRoute: omitting unmanaged node %q", kubeRoute.TargetNode)

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign


Question: spc.setsIndexer.Add(set) ssc.enqueueStatefulSet(set) fakeWorker(ssc) <del> pods, err = spc.addTerminatedPod(set, ord) </del> <ins> pods, err = spc.addTerminatingPod(set, ord) </ins> pod = getPodAtOrdinal(pods, ord) ssc.updatePod(&prev, pod) fakeWorker(ssc)

/assign flakes in PR jobs more than once per day The can filter down to searching for results for a single test:
This test continues to flake PRs at least once per day:
https://k8s-
looking at it


Question: e2evolume.VerifyExecInPodSucceed(f, pod, fmt.Sprintf("echo %s | base64 -d | dd of=%s %s bs=%d count=1", encoded, pathForVolMode, oflag, len)) } <ins> // GetSectorSize returns the sector size of the device. func GetSectorSize(f *framework.Framework, pod *v1.Pod, device string) int { stdout, _, err := e2evolume.PodExec(f, pod, fmt.Sprintf("blockdev --getss %s", device)) framework.ExpectNoError(err, "Failed to get sector size of %s", device) ss, err := strconv.Atoi(stdout) framework.ExpectNoError(err, "Sector size returned by blockdev command isn't integer value.") return ss } </ins> // findMountPoints returns all mount points on given node under specified directory. func findMountPoints(hostExec HostExec, node *v1.Node, dir string) []string { result, err := hostExec.IssueCommandWithResult(fmt.Sprintf(`find %s -type d -exec mountpoint {} ; | grep 'is a mountpoint$' || true`, dir), node)

From here we see that the method takes 512 bytes sector size as a default option for verifying block read. This makes the test fail for the block devices that uses 4k sector size because the read is using . However, with modern kernels the area being operated on, must be aligned to and its size must be a multiple of the disk's block size. So using dd iflag=direct with size 512B on a 4k sector size device will fail. This is introduced in this PR: There should be proper handling of different block sector size for the test. Either a customizable parameter or something. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /cc /sig storage
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
Since we are using Debian image for this test. I am wondering does it make sense to use instead of for the dd read? I guess my question is if we use , while it read after the cache is dropped or before?
Or I am wondering can we just change the size to 4096. A read/write to the multiply of the sector size should be okay I guess?
I am not sure that option is available now, notes from September last year () indicate I tried that as well. I think you still need to write blocks of 512 or 4096 bytes, not sure if (or the kernel) is smart enough to split larger requests into smaller blocks. has a pointer to detect the blocksize dynamically, which would be a cleaner way and more future proof.
I am not sure when you mention the "option is not available" you mean for busybox or debian. I think for this specific test we are using Debian image which has this option.

Yes, this is what we use in the test and we found the test fail because in our case shows 4096 instead of 512
The option () used to be only applicable for (in Debian and CentOS) with , not with . I do not know if the Debian image was updated, and if it contains a new that supports the option.
+1 for using 4096 bytes. Or even more, 1MiB? Kernel/dd is smart and it will handle sequence of well.
I think that it's OK to just use large block size if there's no issue by doing so. However, I've made a PoC implementation of auto detect logic of sector size to compare alternative ideas. One issue is that current debian-iptables image that is used for this test doesn't contain blockdev command. In the PoC code, it is installed on execution time, however it should be included in the image, by either (1) adding it to debian-iptables image or (2) creating a new image that include it. If the issue can be resolved easily, this alternative approach will also be good.
I found that image contains both command and command and can be used for this test. I think that this additional detection logic is simple enough, so I made a PR above. Could you review it?


Question: "//pkg/api:go_default_library", "//pkg/apis/extensions:go_default_library", "//pkg/apis/extensions/validation:go_default_library", <ins> "//vendor:k8s.io/apimachinery/pkg/api/equality", </ins> "//vendor:k8s.io/apimachinery/pkg/fields", "//vendor:k8s.io/apimachinery/pkg/labels", "//vendor:k8s.io/apimachinery/pkg/runtime",

Kubernetes version (use ): Environment: Cloud provider or hardware configuration: DigitalOcean OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others: What happened: when I do: it will run rolling update ONLY if there is a change. In case I do: Each time I run it - it will execute rolling update, which is misleading. What you expected to happen: I would like to have consistent behavior for Deployment and DaemonSet How to reproduce it (as minimally and precisely as possible): Create any DaemonSet with following:
Hmm, it shouldn't happen. TemplateGeneration is updated only when something changed. I will debug it.
I can reproduce this, and the DaemonSet is updated after every , even when nothing is changed. In , old/new DaemonSet template are seen as different with . I tried to change this part to use instead (needed to update code in validation as well), and the DaemonSet templates were then seen as the same, and thus the issue was gone. We used everywhere in the controllers. Is the right way to compare stuffs?
It's very strange. I tried to use pretty.Diff to print the differences but it returns empty slice. apiequality.Semantic.DeepEqual uses forked version of reflect.DeepEqual and it's little different from version in 1.7. will you prepare the patch?
The key of the reported DaemonSet config is its . Note that in the config file, (empty list); however, in the live DaemonSet object (created from the config file), (null list). That's why thinks they're different. If we use in the config file instead, won't change. From the field description, empty list and null list are different. Feel it's api machinery related
protobuf storage isn't able to store , so the object has that field set to when read back from storage. that is causing problems for that field in particular (where and have different meanings) see
cc for behavior of namespaces field
so it's not a DaemonSet bug
Well, still not sure whether Semantic.DeepEqual should be used or not. I'm still concerned with the behavior of the controller for other fields that can be populated with non-null empty lists by users, but serialize back out to null (or set omitempty)
deployments are using Maybe we should also switch?

If empty lists should be treated differently from null list, we should replace with in controller code.
that distinction is going away in all the fields I know of... I'm not super happy with Semantic.DeepEqual masking the difference between those two things, but that's probably the right thing for you to be using
Special meaning of [] was removed in I think a switch to Semantic.DeepEqual is still needed here
Filed


Question: import ( "fmt" <ins> "strconv" </ins> "strings" "k8s.io/kubernetes/pkg/api/v1" netsets "k8s.io/kubernetes/pkg/util/net/sets" <ins> "github.com/golang/glog" </ins> ) const (

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS m4.2xlarge OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-36-generic Install tools: kubeadm Others: 1 master and 1 minion What happened: This states that if using kube-proxy will only proxy requests to local endpoints, never forwarding traffic to other nodes and thereby preserving the original source IP address. However when I annotate my NodePort type service with this annotation I see the following error in the logs of kube-proxy of the node where the only pod of the service is running: After this message the service stops working outside of the cluster on the specified NodePort. What you expected to happen: I expected to see that only the with the pod on it serves traffic. How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
Sorry, I have found the issue, I had a setup where the none of the node names were the same as the hostname of the kube-proxy pod and this caused the issue, where none of the Pods running on a hosts were recognised as local pods. I have fixed this issue by manually setting the hostname with in kube-proxy. However I still insist that this error message is misleading and shouldn't be printed in case of NodePort type services, but only for just LoadBalancers.
I met the same problem in the aws cloud providers, by adding - the hostname-override to solve this problem. good


Question: }, }, }, <ins> { name:           "skipped prescore plugin number greater than the number of score plugins", plugins:        buildScoreConfigDefaultWeights(scorePlugin1), pluginConfigs:  nil, skippedPlugins: sets.New(scorePlugin1, "score-plugin-unknown"), want: []framework.NodePluginScores{ { Name:   "node1", Scores: []framework.PluginScore{}, }, { Name:   "node2", Scores: []framework.PluginScore{}, }, }, }, </ins> } for _, tt := range tests {

When initializing kube-scheduler, We provided a custom config file for KubeSchedulerConfiguration and disabled the score plugin. This resulted in a panic in kube-scheduler at kube-scheduler up and running Using the below KubeSchedulerConfiguration file to enable kube-scheduler. apiVersion: kind: KubeSchedulerConfiguration clientConnection: kubeconfig: profiles: plugins: score: disabled: name: '*' extenders: urlPrefix: https://127.0.0.1:/scheduler filterVerb: "predicates" weight: 1 httpTimeout: 60s enableHTTPS: true nodeCacheCapable: false ignorable: false While trying to debug the issue, I found a change done recently for preScore calculation which might be causing the issue When we disable only the Score plugin then scheduler configuration will result in default preScorePlugins with 3 enabled [NodeResourcesFit, InterPodAffinity, TaintToleration] And due to this change, the preScore for InterPodAffinity results in skip status for some case (still not able to figured out what exactly it is), and this might result in a panic for kube-scheduler. The numplugin variable turns out to be negative. 28.3 N/A No response kubeadm No response No response
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
Let me take a look.
/assign
maybe related to
Past me argued this in the PR
scheduler-plugins' integration test also hits this: To end-users: if the fix () or its cherrypicks are not around in your k8s cluster. The workaround is that when disabling Score plugins, ensure to disable their PreScore counterparts as well.


Question: resources: ["backendconfigs"] verbs: ["get", "list", "watch", "update", "create", "patch"] - apiGroups: ["networking.gke.io"] <del> resources: ["servicenetworkendpointgroups"] </del> <ins> resources: ["servicenetworkendpointgroups","gcpingressparams"] verbs: ["get", "list", "watch", "update", "create", "patch"] # GLBC creates and updates `networking.k8s.io/IngressClass` - apiGroups: ["networking.k8s.io"] resources: ["ingressclasses"] </ins> verbs: ["get", "list", "watch", "update", "create", "patch"]

<!-- 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: Anything else we need to know: /cc /sig network /priority important-soon /milestone v1.20
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
xref
/assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
This has been green for a while now. Should we close this one?
I would ideally like to see a statement that this was triaged, had a root cause analysis done, had a fix for the root cause applied, and that the fix was monitored and deemed successful. Hey can you take a look at let us know if you are happy to that this flake has been figured out and fixed? is correct, this looks green. but this does not
Flaked today: And triage also shows that the version of this test has been having a bad time for a long time on :
I think there was a CI change that caused this to go green. Will follow up.
I am looking at this test grid. It is relatively green. Am I looking at the right one?
Yes, that's the one where this one is. But there is also a one that Rob and I are referring to which is here: and has not passed for a while.
Can we remove this from SIG-Net in favor of GCE or GKE cloudprovider? If this is mostly to due with NEG, it likely only applies to the GKE specific test.
What do we do with this one?
this continues to fail hundreds of times a day - if the thing it is testing is important, should this be prioritized? if not, should the test be removed?

we have several of these, and despite they are tagged as sig-network most of them seems to be GCE only tests. I'm tagging you because you'll have better visibility. Maybe we should define clearly the ownership, is this sig-network, gce or cloud-provider? and then the owner decide if we want to run them or fix them, leaving tests failing in this limbo is not useful as Jordan correctly pointed out
+100 for not staying in that state - we should either prioritize or remove. Re ownership - I don't have strong opinion here. But for sure the name is misleading if the tests are GCE-specific (I would expect "conformance" stuff to not be gce-specific. What are the arguments against 'sig-network' owning it? It's just that you don't want to debug GCE-specific stuff? Or some more fundamental ones (like ability to iterate etc.)?
I didn't dig too much into the tests because I always assumed that was testing GCE only things, but it is possible that I'm wrong. I personally don't have problem on debugging GCE stuff, is the ability to iterate and the codebase that is being tested that worries me: is any person able to debug the test? are there parts of the test that need "internal GCE" access to debug it? is the test testing kubernetes network or gce cloud-provider, gce ingress, ....?
I think that everything should be accessible - to confirm. Technically, many networking (and other) tests are relying on cloud-provider (e.g. all tests that exercise LoadBalanced service). So that isn't unique (do we have complaints about these tests too)? So what make ingress tests different is a separate out-of-tree controller, I guess. [To be clear - I'm not trying to push sig-network to own that, i'm just trying to understand the arguments better.]
Let me share my thoughts, I'm personally trying to make all the dashboards in sig-network green, and this week I was able to sort out most of the problems, the last flake with TCP CLOSE_WAIT seems solved, and everything is acceptable except in GCE and Azure jobs.

The dual-stack azure jobs are pending of a new image version bump, but I know there is an Azure person that is taking responsibility and will be working on fixing it: For GCE jobs I use to ping or and you can see that the gce dashboard is in a good state However, there are GCE jobs that are in very bad state, failing continuously, I'm practically doing this by myself, that is a personal decision, spending some time every day to review the dashboards and addressing the "generic" failures, but my time is limited, so if this has to go under sig-network umbrella I just want to be sure that these are really needed and, if they are GCE only features, asking for some help from GCE folks.
I agree we're relying to much on heroics of individual people that isn't sustainable. I think those are valid questions, but I would first like to hear from network folks with Google too.
is taking a look
This might just be a issue with 10m not being quite enough for 100% of the time to pass.
Strike my comment -- looks like there is test related issue.
The tests are failing because glbc needs new rbac permissions for IngressClass and GCPIngressParams. adds those which should cause the the failures to stop.
/assign Thanks guys, we are close to be completely green in sig-network :smile:
to fix the
/reopen It seems only 2 tests were fixed, there are still 7 failing tests
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
maybe this error failure gives you a hint
seem to show another rbac issue:
patch permission to services/status has to be granted separately
adds the permission
Is this resolved yet? I just saw another failure today -
The most recent failure does not look to be because of rbac permissions. But I realize this issue is tracking multiple errors and this error looks more similar to the original problem described. The rbac permissions in has not been merged in yet.

/milestone v1.21 (marking in the current milestone until we get confirmation whether it is relevant to the release or not)
Slack Discussion Thread:
I have been looking at the test failure: This failure actually is a different test than the one this issue was opened with. Looking at the logs, there does not seem to be a clear indication of the root cause. The error is because the loadbalancer comes up within the timeout but the path has not be configured leading to the 404. Looking at the logs, the error seems to be outside of the Kubernetes release and therefore this flake should not be considered as release blocking.
/milestone clear (since this has been deemed to be non release-blocking)
Current logs are not enough to determine the issue. For now, opened to update the glbc image which should give us more instrumentation. The timeout is currently 10 min. One theory is that this sometimes is not enough for the loadbalancer to be ready. The LB comes up, but the path is not available yet. However since the the timeout is currently shared amongst many different tests, I propose we wait until we can determine that is the root cause before increasing the timeout.
this is much better now, only one failures in the last 10 days and the failures is as you said:
Can we update the timeout to 2x (20 min) -- I think this will drop failures significantly.
The timeout is set in a helper method: and uses: Are we okay changing it for all the tests that use that, or do we only want to target this one?
Let's target it for this test -- as I think this is the only one that will require such a long timeout.
:upsidedownface: if you want to be on the safe side :) :)
This still needs more work, while working past week on the ingress v1beta1 problems I found that sometimes the client that polls the LB hangs, we should at least have a better logging to understand which part is broken on the test. Is the client? the LB? something between both?
-- any code reference? Improving the client logging sounds like an easy PR
It failed twice the last week, but now is failing in another point can you PTAL, what is that certificate error?

/milestone v1.22
it only failed once, last week, however, the job is running every 30 min that seems excessive. I'll update the job to run with a larger interval and we'll keep monitoring it
Decreasing period sounds good to me.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: }, } <del> for _, tt := range tests { cache := newSchedulerCache(ttl, time.Second, nil) </del> <ins> for i, tt := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { cache := newSchedulerCache(ttl, time.Second, nil) </ins> <del> if err := tt.handler(cache, tt.pod); err != nil { t.Fatalf("unexpected err: %v", err) } </del> <ins> if err := tt.handler(cache, tt.pod); err != nil { t.Fatalf("unexpected err: %v", err) } </ins> <del> if !tt.assumePod { if err := cache.UpdatePod(tt.pod, tt.podToUpdate); err != nil { t.Fatalf("UpdatePod failed: %v", err) </del> <ins> if !tt.assumePod { if err := cache.UpdatePod(tt.pod, tt.podToUpdate); err != nil { t.Fatalf("UpdatePod failed: %v", err) } </ins> } <del> } cachedPod, err := cache.GetPod(tt.pod) if err != nil { t.Fatalf("GetPod failed: %v", err) } if !reflect.DeepEqual(tt.podToUpdate, cachedPod) { t.Fatalf("pod get=%s, want=%s", cachedPod, tt.podToUpdate) } </del> <ins> cachedPod, err := cache.GetPod(tt.pod) if err != nil { t.Fatalf("GetPod failed: %v", err) } if !reflect.DeepEqual(tt.podToUpdate, cachedPod) { t.Fatalf("pod get=%s, want=%s", cachedPod, tt.podToUpdate) } }) </ins> } }

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign


Question: } os.MkdirAll(dir, 0750) <ins> // check whether it belongs to fuse, if not, default to use kernel mount. if cephfsVolume.checkFuseMount() { glog.V(4).Infof("CephFS fuse mount.") err = cephfsVolume.execFuseMount(dir) // cleanup no matter if fuse mount fail. keyringPath := cephfsVolume.GetKeyringPath() _, StatErr := os.Stat(keyringPath) if !os.IsNotExist(StatErr) { os.RemoveAll(keyringPath) } if err == nil { // cephfs fuse mount succeeded. return nil } else { // if cephfs fuse mount failed, fallback to kernel mount. glog.V(4).Infof("CephFS fuse mount failed: %v, fallback to kernel mount.", err) } } glog.V(4).Infof("CephFS kernel mount.") </ins> err = cephfsVolume.execMount(dir) <del> if err == nil { return nil </del> <ins> if err != nil { // cleanup upon failure. util.UnmountPath(dir, cephfsVolume.mounter) return err </ins> } <del> // cleanup upon failure util.UnmountPath(dir, cephfsVolume.mounter) // return error return err </del> <ins> return nil </ins> } type cephfsUnmounter struct {

The goal of this issue is to design a CephFS driver using FUSE client for Kubernetes.</brExisting Ceph kernel client has the following drawbacks:</br• Kernel client does not support client-enforced quotas. • Kernel CephFS doesn't support quota or capacity, capacity requested by PVC is not enforced or validated. • Kernel CephFS doesn't work with SELinux, setting SELinux label in Pod's security context will not work.
Just a detail. Since we will rely on ceph-fuse, we will need the ceph-fuse client to be available on all kubernetes nodes. We can add a parameter to allow the use of the kernel client as well. I would say better make the fuse client opt-in and keep the kernel one as the default option. The kernel client might support quotas in the future. Thanks
/sig storage
We are also inclined to use fuse instead of kernel client ,any progress on this issue?
I like to continue this job and prepare to send a PR to make kubernetes support cephfs fuse mounting.
/assign I think this task would be valuable. =)
waiting for the PR, do you have a plane to support s3 fuse ?
No, no plan for s3fs-fuse currently
also see and cc
Ceph-fuse support in the command to display the specified secret, it may take some time to support, because it involves LibFUSE(I will follow up this demand). On the other hand, ceph-fuse has stability, quota function, expansion, upgrade and other advantages. Although ceph-fuse only supports the secret file way, but if it can be pushed to the k8s community, there is a very meaningful thing.


Question: } // Version returns the runtime name, runtime version and runtime API version <del> func (ds *dockerService) Version(apiVersion string) (*runtimeApi.VersionResponse, error) { </del> <ins> func (ds *dockerService) Version(_ string) (*runtimeApi.VersionResponse, error) { </ins> v, err := ds.client.Version() if err != nil { return nil, fmt.Errorf("docker: failed to get docker version: %v", err) } runtimeAPIVersion := kubeAPIVersion name := dockerRuntimeName <ins> // Docker API version (e.g., 1.23) is not semver compatible. Add a ".0" // suffix to remedy this. apiVersion := fmt.Sprintf("%s.0", v.APIVersion) </ins> return &runtimeApi.VersionResponse{ Version:           &runtimeAPIVersion, RuntimeName:       &name, RuntimeVersion:    &v.Version, <del> RuntimeApiVersion: &v.APIVersion, </del> <ins> RuntimeApiVersion: &apiVersion, </ins> }, nil }

umbrella issue: kuberuntime uses to ]parse the version string of the api version]() from the runtime. When using with docker, it complains that Maybe we should just enforce that the api version returned by the runtime should be semver compatible. /cc
This is mentioned in . :) For now, we can add a after the docker apiversion to make it semver compatible.
Thanks for the reminder! We should make it clear in the API. This blocks kubelet from starting up, so we should fix it first.
I've checked the code, currently is only used in when checking the docker version compatibility. It is not exposed to the user by any means, so it should be fine to make some change ourselves, such as adding a . However, if we want to expose this to the user via in the future, it may make user confusing.


Question: number of Replicas. release: v1.19 file: test/e2e/scheduling/preemption.go <ins> - testname: Scheduler, Verify PriorityClass endpoints codename: '[sig-scheduling] SchedulerPreemption [Serial] PriorityClass endpoints verify PriorityClass endpoints can be operated with different HTTP methods [Conformance]' description: Verify that PriorityClass endpoints can be listed. When any mutable field is either patched or updated it MUST succeed. When any immutable field is either patched or updated it MUST fail. release: v1.20 file: test/e2e/scheduling/preemption.go </ins> - testname: Scheduler, Basic Preemption codename: '[sig-scheduling] SchedulerPreemption [Serial] validates basic preemption works [Conformance]'

The following PriorityClass endpoints was Promoted it 1.14 without Conformance tests, and remain untested: replace-, read-, patch-, list-, delete-collection- SchedulingV1PriorityClass According to this APIsnoop query, there are still some remaining PriorityClass endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints ! createSchedulingV1PriorityClass deleteSchedulingV1PriorityClass Promoted to Conformance 1.19 with /sig testing /sig architecture /area conformance
Is the ultimiate goal to use conformance tests to explicitly issue all CRUD requests against PriorityClass? And, is equivalent to "update PriorityClass"?
all APIs must have Conformance tests unless they are not eligible for Conformance due to the There is other APIGroups that have both Replace and Update as endpoints. That is the prerogative of the SIG to decide.
can you please point us to similar conformance tests used for core objects such as pods and nodes?
This is a life cycle test for Create, List, Update, Patch, DeleteCollection More can be found in the test/e2e folder. Also look for examples on the Conformance at previously Promoted Conformance test Reach out if we can help with more information on our approach to Conformance testing.
I remembered about this PR. Last week a few lines of code was to cover the last of the "Lease" endpoint group for conformance. The one file contain the Conformance tests for the complete life cycle of Lease endpoints.
/assign I will work on it.
/reopen Will monitor in test grid to move to Conformance after 2 weeks soak.
Reopened this issue. <detailsIn response to : /reopen Will monitor in test grid to move to Conformance after 2 weeks soak. </details
/triage accepted


Question: "reflect" "testing" <ins> "github.com/stretchr/testify/assert" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/client-go/kubernetes/fake" utiltesting "k8s.io/client-go/util/testing" "k8s.io/kubernetes/pkg/util/mount"

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign


Question: expected:       nil, expected_error: true, }, <ins> { // All existing cipher suites flag: []string{ "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_RSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305", "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305", "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_256_GCM_SHA384", "TLS_RSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA", "TLS_ECDHE_RSA_WITH_RC4_128_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", }, expected: []uint16{ tls.TLS_RSA_WITH_3DES_EDE_CBC_SHA, tls.TLS_RSA_WITH_AES_128_CBC_SHA, tls.TLS_RSA_WITH_AES_256_CBC_SHA, tls.TLS_RSA_WITH_AES_128_GCM_SHA256, tls.TLS_RSA_WITH_AES_256_GCM_SHA384, tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, tls.TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, tls.TLS_AES_128_GCM_SHA256, tls.TLS_CHACHA20_POLY1305_SHA256, tls.TLS_AES_256_GCM_SHA384, tls.TLS_RSA_WITH_RC4_128_SHA, tls.TLS_RSA_WITH_AES_128_CBC_SHA256, tls.TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, tls.TLS_ECDHE_RSA_WITH_RC4_128_SHA, tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, }, }, </ins> } for i, test := range tests { uIntFlags, err := TLSCipherSuites(test.flag) <del> if reflect.DeepEqual(uIntFlags, test.expected) == false { </del> <ins> if !reflect.DeepEqual(uIntFlags, test.expected) { </ins> t.Errorf("%d: expected %+v, got %+v", i, test.expected, uIntFlags) } if test.expected_error && err == nil {

Once we upgrade to go1.14, we can use the new CipherSuites and InsecureCipherSuites functions and CipherSuiteName function to build the supported cipher suite flags. /sig api-machinery
/sig auth
/cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
as the project was upgraded to go-1.14+ is that still something that needs to be done?
yes, these manually maintained maps should be swapped to the stdlib impls:
/assign
/triage accepted Thanks,


Question: } } <del> func (h *hostpathDriver) CreateDriver() { </del> <ins> func (h *hostPathDriver) CreateDriver() { </ins> } <del> func (h *hostpathDriver) CleanupDriver() { </del> <ins> func (h *hostPathDriver) CleanupDriver() { </ins> } <del> func (h *hostpathDriver) CreateVolume(volType testpatterns.TestVolType) { </del> <ins> func (h *hostPathDriver) CreateVolume(volType testpatterns.TestVolType) { </ins> f := h.driverInfo.Framework cs := f.ClientSet

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: https://k8s- What happened: The skip check for hostpath doesn't seem to be working for these test cases
can you take a look?
Oh, disruptive tests are the tests that can't be tested locally in my environment due to I will take a look.
I found that above issue is not related, I should have been checked more carefully. Sorry for that.
I found out that this was just a driver name issue, so below will fix it: hostpath -hostPath hostpathSymlink -hostPathSymlink We might be better changing the skip logic later, to make it skip not by name in order to avoid this kind of bug, though. I will make a PR for above change, soon.
I made a PR above. Also, it might be a bit out of scope of this fix, but are drivers tested with containerized volume server, like nfs, ceph, etc..., safe to be tested with subpath disruptive tests? I'm worrying about the case that test pod and containerized volume server are deployed on the same node. In such a case, the same behaviour expected or do we need to avoid this kind of situation?


Question: if tc.reportedPodReadiness != nil { podReadiness = tc.reportedPodReadiness[i] } <ins> podPhase := v1.PodRunning if tc.reportedPodPhase != nil { podPhase = tc.reportedPodPhase[i] } </ins> podName := fmt.Sprintf("%s-%d", podNamePrefix, i) pod := v1.Pod{ Status: v1.PodStatus{ <del> Phase: v1.PodRunning, </del> <ins> Phase: podPhase, </ins> Conditions: []v1.PodCondition{ { Type:   v1.PodReady,

/kind bug What happened: HPA fails to launch additional pods due to pods in evicted state, even with utilization significantly over target. What you expected to happen: When HPA pods reach the target utilization, new pods should be allocated and provisioned. How to reproduce it (as minimally and precisely as possible): Launch a HPA, let the pods fill the disk on the host which will trigger evictions due to "Pod The node was low on resource: [DiskPressure]", HPA will exceed target and not allocate additional pods. Anything else we need to know?: Seems related to and though those are not specific to HPA. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): cos-stable-57-9202-64-0 kernel commit id Kernel (e.g. ):Linux gke-prod1-use1b-v2--35s4 4.4.70+ SMP Mon Sep 18 12:43:08 PDT 2017 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux
/sig scheduling
Are there any workarounds while we wait for a fix? We have ran into this on a 1.8.4 GKE cluster.
/sig autoscaling /remove-sig scheduling
I am thinking of fixing this by excluding pods with Phase=Failed from the unreadyPods that are taken into account. It seems the right thing to do as they will not become running again. Do you see any issues?
that seems decent -- anything that will never be running again should not be factored into our calculations.
/status approved-for-milestone Adding to milestone -- if the HPA isn't functioning in the case of evictions, that seems like a decently severe HPA bug.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues.

Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details


Question: # this uses the API port because if you don't have any authenticator, you can't seem to use the secure port at all. # this matches what happened with the combination in 1.4. # TODO change this conditionally based on whether API_PORT is on or off <del> kube::util::wait_for_url "http://${API_HOST_IP}:${API_SECURE_PORT}/healthz" "apiserver: " 1 ${WAIT_FOR_URL_API_SERVER}  </del> <ins> kube::util::wait_for_url "https://${API_HOST_IP}:${API_SECURE_PORT}/healthz" "apiserver: " 1 ${WAIT_FOR_URL_API_SERVER}  </ins> || { echo "check apiserver logs: ${APISERVER_LOG}" ; exit 1 ; } # Create kubeconfigs for all components, using client certs

<!-- 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.): local-up- Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: KVM OS (e.g. from /etc/os-release): fedora 25 Kernel (e.g. ): uname -a Linux k8sbuild-master 4.11.3-200.fc25.x8664 SMP Thu May 25 19:03:07 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others: What happened: local-up- fails to create kube-dns and StorageClass. What you expected to happen: local-up- is successfully executed. How to reproduce it (as minimally and precisely as possible): 1) Clone kubernetes from master branch 2) run local-up- $ export ENABLEHOSTPATHPROVISIONER="true"; ./hack/local-up- If you already have kubernetes , try this 1) make cleanmeta 2) run local-up- $ export ENABLEHOSTPATHPROVISIONER="true"; ./hack/local-up- Anything else we need to know: I think this problem is timing issue because sleeping 3 seconds before startkubedns can avoid this problem.
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 and label list
/sig testing /sig storage /sig network
/sig apps
I met the same issue we should add a function to check if all api-versions are up


Question: k8s.io/sample-apiserver => ./staging/src/k8s.io/sample-apiserver k8s.io/sample-cli-plugin => ./staging/src/k8s.io/sample-cli-plugin k8s.io/sample-controller => ./staging/src/k8s.io/sample-controller <del> k8s.io/system-validators => k8s.io/system-validators v1.5.0 </del> <ins> k8s.io/system-validators => k8s.io/system-validators v1.6.0 </ins> k8s.io/utils => k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b modernc.org/cc => modernc.org/cc v1.0.0 modernc.org/golex => modernc.org/golex v1.0.0

every k8s release, if changes are to we release a new version of the library and vendor it in this repository. TODO: [ ] wait for changes to accumulate in [ ] add new release in before the k8s 1.23 release [ ] vendor the new release in k/k (example PR: )
/sig cluster-lifecycle node /milestone v1.23 /assign
/triage accepted
/cc


Question: } func TestNsenterExistsFile(t *testing.T) { <ins> user, err := user.Current() if err != nil { t.Error(err) } isRoot := user.Username == "root" </ins> tests := []struct { name           string prepare        func(base, rootfs string) (string, error)

Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: TestNsenterExistsFile test is failing during make test What you expected to happen: The test should have passed. How to reproduce it (as minimally and precisely as possible): git clone run make test Anything else we need to know?: Fail logs: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig storage
If you run the test with root user, It will fail. I have make a fix:
thanks for the patch .. its working.


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 set import ( "errors" "fmt" "io" "github.com/spf13/cobra" "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/types" utilerrors "k8s.io/apimachinery/pkg/util/errors" "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/kubectl/cmd/templates" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "k8s.io/kubernetes/pkg/kubectl/resource" "k8s.io/kubernetes/pkg/util/i18n" ) var ( serviceaccountResources = ` replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset` serviceaccountLong = templates.LongDesc(i18n.T(` Update ServiceAccount of pod template resources. Possible resources (case insensitive) can be: ` + serviceaccountResources)) serviceaccountExample = templates.Examples(i18n.T(` # Set Deployment nginx-deployment's ServiceAccount to serviceaccount1 kubectl set serviceaccount deployment nginx-deployment serviceaccount1 # Print the result (in yaml format) of updated nginx deployment with serviceaccount from local file, without hitting apiserver kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run -o yaml `)) ) // serviceAccountConfig encapsulates the data required to perform the operation. type serviceAccountConfig struct { fileNameOptions        resource.FilenameOptions mapper                 meta.RESTMapper encoder                runtime.Encoder out                    io.Writer err                    io.Writer dryRun                 bool shortOutput            bool all                    bool record                 bool output                 string changeCause            string local                  bool saPrint                func(obj runtime.Object) error updatePodSpecForObject func(runtime.Object, func(*api.PodSpec) error) (bool, error) infos                  []*resource.Info serviceAccountName     string } // NewCmdServiceAccount returns the "set serviceaccount" command. func NewCmdServiceAccount(f cmdutil.Factory, out, err io.Writer) *cobra.Command { saConfig := &serviceAccountConfig{ out: out, err: err, } cmd := &cobra.Command{ Use:     "serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT", Aliases: []string{"sa"}, Short:   i18n.T("Update ServiceAccount of a resource"), Long:    serviceaccountLong, Example: serviceaccountExample, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(saConfig.Complete(f, cmd, args)) cmdutil.CheckErr(saConfig.Run()) }, } cmdutil.AddPrinterFlags(cmd) usage := "identifying the resource to get from a server." cmdutil.AddFilenameOptionFlags(cmd, &saConfig.fileNameOptions, usage) cmd.Flags().BoolVar(&saConfig.all, "all", false, "Select all resources in the namespace of the specified resource types") cmd.Flags().BoolVar(&saConfig.local, "local", false, "If true, set image will NOT contact api-server but run locally.") cmdutil.AddRecordFlag(cmd) cmdutil.AddDryRunFlag(cmd) return cmd } // Complete configures serviceAccountConfig from command line args. func (saConfig *serviceAccountConfig) Complete(f cmdutil.Factory, cmd *cobra.Command, args []string) error { saConfig.mapper, _ = f.Object() saConfig.encoder = f.JSONEncoder() saConfig.shortOutput = cmdutil.GetFlagString(cmd, "output") == "name" saConfig.record = cmdutil.GetRecordFlag(cmd) saConfig.changeCause = f.Command(cmd, false) saConfig.dryRun = cmdutil.GetDryRunFlag(cmd) saConfig.output = cmdutil.GetFlagString(cmd, "output") saConfig.updatePodSpecForObject = f.UpdatePodSpecForObject saConfig.saPrint = func(obj runtime.Object) error { return f.PrintObject(cmd, saConfig.local, saConfig.mapper, obj, saConfig.out) } cmdNamespace, enforceNamespace, err := f.DefaultNamespace() if err != nil { return err } if len(args) == 0 { return errors.New("serviceaccount is required") } saConfig.serviceAccountName = args[len(args)-1] resources := args[:len(args)-1] builder := f.NewBuilder(!saConfig.local).ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). FilenameParam(enforceNamespace, &saConfig.fileNameOptions). Flatten() if !saConfig.local { builder.ResourceTypeOrNameArgs(saConfig.all, resources...). Latest() } saConfig.infos, err = builder.Do().Infos() if err != nil { return err } return nil } // Run creates and applies the patch either locally or calling apiserver. func (saConfig *serviceAccountConfig) Run() error { patchErrs := []error{} patchFn := func(info *resource.Info) ([]byte, error) { saConfig.updatePodSpecForObject(info.Object, func(podSpec *api.PodSpec) error { podSpec.ServiceAccountName = saConfig.serviceAccountName return nil }) return runtime.Encode(saConfig.encoder, info.Object) } patches := CalculatePatches(saConfig.infos, saConfig.encoder, patchFn) for _, patch := range patches { info := patch.Info if patch.Err != nil { patchErrs = append(patchErrs, fmt.Errorf("error: %s/%s %vn", info.Mapping.Resource, info.Name, patch.Err)) continue } if saConfig.local || saConfig.dryRun { saConfig.saPrint(patch.Info.Object) continue } patched, err := resource.NewHelper(info.Client, info.Mapping).Patch(info.Namespace, info.Name, types.StrategicMergePatchType, patch.Patch) if err != nil { patchErrs = append(patchErrs, fmt.Errorf("failed to patch ServiceAccountName %v", err)) continue } info.Refresh(patched, true) if saConfig.record || cmdutil.ContainsChangeCause(info) { if patch, patchType, err := cmdutil.ChangeResourcePatch(info, saConfig.changeCause); err == nil { if patched, err = resource.NewHelper(info.Client, info.Mapping).Patch(info.Namespace, info.Name, patchType, patch); err != nil { fmt.Fprintf(saConfig.err, "WARNING: changes to %s/%s can't be recorded: %vn", info.Mapping.Resource, info.Name, err) } } } if len(saConfig.output) > 0 { saConfig.saPrint(patched) } cmdutil.PrintSuccess(saConfig.mapper, saConfig.shortOutput, saConfig.out, info.Mapping.Resource, info.Name, saConfig.dryRun, "serviceaccount updated") } return utilerrors.NewAggregate(patchErrs) } </ins>

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): HEAD Now that RBAC is going to GA, using ServiceAccounts is getting more and more important. Still a lot of users run their apps/addons/whatever in the SA. In order for the admin to be able to change ServiceAccount easily after an application has been installed (which supposedly is crashlooping due to insufficient privs), a command could exist. I know I can do this: but for new users to Kubernetes, it's non-obvious. Proposed command: Tracking issue: WDYT? This would be a good way for a new contributor to get aquainted with the code by contributing this feature.
Is anyone working on this? If not I would like to take this up.
Nobody is working on this. I would be super happy if you could contribute this feature. Be aware of that there isn't consensus around this proposal yet (I proposed it yesterday, saturday, so people haven't had time to catch up on it) However, I do think that this is in line with , so feel free to start working on this if you want to ;) Also, don't hesitate to ask for help if you don't know how to get started and we'll help out! Thanks!
I'm in favor of this command. ?
Thanks, I will start working on this.
Is the SA on a Pod mutable or immutable? What about DaemonSet and StatefulSet? Do those have SA as well? Is there a way to do this so that it dynamically supports anything with a PodTemplate? Maybe this should be done as a subresource that can be dynamically discovered by kubectl using the discovery service.
Maybe helpful:
Pod is immutable. All the other objects (with the exception of stateful set) are mutable.
That pattern is the same for all the things that set aspects of a pod spec (except image, which is also mutable in pods)
Statefulsets are going to loosen their validation soon I expect.
This sounds good to me. just go ahead, I will help review this. Thanks ~
The outout of this command kubectl get rc/nginx-controller -o=yaml , has service acccount at the following path '' , and the corresponding pod has service account at 'spec.serviceAccountName'.

Both refer to the 'serviceAccountName' field of PodSpec struct but can be made to be different by patching the ReplicationController resource. How does ReplicationController and Pod use serviceAccountName differently? Shouldn't the ReplicationControllerSpec have a serviceAccountName field?
ptal, I think you are more familiar with ReplicationController implementation than me.
ReplicationController contains a pod spec object, which contains a serviceAccountName.
Hi , how to go about writing e2e test cases for this. My development is mostly complete.
I wouldn't mind if you posted the PR now and then we'd see what e2e test makes sense to have. In order to move forward...
what are the next steps?


Question: gvr("internal.apiserver.k8s.io", "v1alpha1", "storageversions"):     `{"status": {"commonEncodingVersion":"v1","storageVersions":[{"apiServerID":"1","decodableVersions":["v1","v2"],"encodingVersion":"v1"}],"conditions":[{"type":"AllEncodingVersionsEqual","status":"True","lastTransitionTime":"2020-01-01T00:00:00Z","reason":"allEncodingVersionsEqual","message":"all encoding versions are set to v1"}]}}`, } <del> const statusDefault = `{"status": {"conditions": [{"type": "MyStatus", "status":"true"}]}}` // DO NOT ADD TO THIS LIST. // This list is used to ignore known bugs. We shouldn't introduce new bugs. var ignoreList = map[schema.GroupVersionResource]struct{}{ // TODO(#89264): apiservices doesn't work because the openapi is not routed properly. gvr("apiregistration.k8s.io", "v1beta1", "apiservices"): {}, gvr("apiregistration.k8s.io", "v1", "apiservices"):      {}, } </del> <ins> const statusDefault = `{"status": {"conditions": [{"type": "MyStatus", "status":"True"}]}}` </ins> // Some status-only APIs have empty object on creation. Therefore we don't expect create_test // managedFields for these APIs

It looks like the openapi is not routed properly to set-up the apiservice so apply requests will fail because the fieldmanager is not set-up properly. /cc /sig api-machinery /priority important-soon /kind bug
/wg apply /cc
OpenAPIModels is set to nil for the kube-aggregator server config (which serves the APIServices API): This is done because the kube-aggregator has a special openapi handler that aggregates all the other server's openapi docs. The field controls (at least) two things: /openapi endpoint serving (which we want kube-aggregator to continue to customize) creation of the field manager (which we want kube-aggregator to behave consistently on) We need to decouple presence of OpenAPIConfig and construction of StaticOpenAPISpec (which is needed by the field manager) from construction/installation of OpenAPIVersionedService. That might be a little tricky to untangle, since construction of StaticOpenAPISpec includes paths/operations. The field manager only needs the gvk/schemas.
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
/lifecycle frozen This is not something we want closed by accident.
/assign
For reference:
Additional lines for reference: This is roughly how SSA consumes the openapi spec. openapi spec -openapi proto model -typeconverter -SSA field manager For built in types, openapi spec -openapi model openapi model -typeconverter A similar thing happens for CRDs As liggitt mentioned, SSA only requires a subset of the information in the openapi generation, and the openapi generation in the aggregator slightly different than the process for builtins and CRDs.
/unassign
/assign


Question: uniquePodName) } <del> dswp.markPodProcessed(uniquePodName) </del> <ins> // some of the volume additions may have failed, should not mark this pod as fully processed if allVolumesAdded { dswp.markPodProcessed(uniquePodName) } </ins> } // podPreviouslyProcessed returns true if the volumes for this pod have already

Deployment/Service manifest: logs from events: In aws, the volume is attached, On the box: In only one is mounted: Where can I debug this further?
Take a look at the on your master for events related to your volume . That will show you when the volume was attached/detached. It appears that your volume attached without issue so there should be nothing unusual here. Then take a look at on the node that the volume is supposed to be attached to. Looks for the UID of your pod (). I suspect one of your mounts is failing. It looks like you are using hyperkube so it might be a mount namespace propagation issue.
I believe this happens when the RC/Pod is being created shortly after the PV or PVC. The latter two appear to need several seconds to be fully available (even if the status is already set to "Bound"). I ran into the same issue with a NFS PV. When I delete and create PV+PVC+SVC+RC all in one go, the associated Pod will be in ContainerCreating state for several seconds (10,<60), then log the warning event and afterwards be created without any problems or further delays. When I first create PV+PVC, wait for several seconds (30) and only then create SVC+RC, the pod will be created immediately and no warning event will be logged. One oddity I noticed is that the PVC will have capacity 0 and empty access modes (as shown by ), even though it was setup to request ROX for 1Gi and the PV provides 1Gi with ROX. This might be a different bug, though.
Thanks for digging into it The capacity 0 issue () was fixed by PR and is in v1.3.5. This is more or less expected behavior. The mount logic has exponential backoff so if it rapidly encounters PVC/PV does not exist, it'll back off the retries resulting in a longer mount time. We can consider optimizing this particular scenario. But I'll lower the priority on this for now and remove the milestone.
Maybe the "Bound" status could be delayed, so the RC would be held back for a while and be scheduled only when the PVC is actually ready?
I don't think the RC actually waits for PVC to be bound before scheduling.

I have also this problem using deployment with HELM, I deploy all my pv,pvc,deploy,svc in one Charts, and my pod who requiere a volume from the PVC get scheduled and stay in ContainerCreating mode. I need to wait minutes or delete pods for they correctly get rescheduled using the volume. Here is the log when the pod get automaticly deleted (after minutes) : It would be awesome if the deployment or RC wait for the PVC to be bound before schedule !
may slightly improve this situation as the maximum backoff time of 2 minutes will not fire anymore.
Note that the same error is thrown when node-size == C5 or M5 for kubectl and with kops . Solution is to set node as t2 machines. Due to it seems.
Reading from the new solution is:


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

/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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 node
/assign


Question: if serverDryRun { patchOptions.DryRun = []string{metav1.DryRunAll} } <del> _, err = client.Patch(context.TODO(), c.node.Name, types.StrategicMergePatchType, patchBytes, patchOptions) </del> <ins> _, err = client.Patch(clientCtx, c.node.Name, types.StrategicMergePatchType, patchBytes, patchOptions) </ins> } else { updateOptions := metav1.UpdateOptions{} if serverDryRun { updateOptions.DryRun = []string{metav1.DryRunAll} } <del> _, err = client.Update(context.TODO(), c.node, updateOptions) </del> <ins> _, err = client.Update(clientCtx, c.node, updateOptions) </ins> } return err, patchErr }

What would you like to be : For , the method of the object should accept a user supplied context which is then used by the client to update the status of the node before cordon/uncordoning the node. Why is this needed: Currently uses a local copy of the drain/cordon code from the codebase. Instead of maintaining a local copy, we would like to incorporate the functionality using upstream imports from . In the CAPI codebase, we pass a object to all the controller Reconcile routines and sub-routines. We would like to keep this same behavior even when we move to importing the drain code from I noticed that the code at does not use a passed context but instead uses a placeholder context for the patch/update calls. Instead, we can modify the method to accept a custom context passed over from the drain helper.
/sig cli
/triage accepted /priority backlog


Question: if err != nil { return err } <ins> if len(rsrc.Versions) == 0 { return fmt.Errorf("ThirdPartyResource %s has no defined versions", rsrc.Name) } </ins> plural, _ := meta.KindToResource(unversioned.GroupVersionKind{ Group:   group, Version: rsrc.Versions[0].Name,

FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.


Question: InitContainers: []v1.Container{ { SecurityContext: &v1.SecurityContext{ <del> RunAsUser: utilptr.Int64Ptr(1000), </del> <ins> RunAsUser: ptr.To[int64](1000), </ins> }, }, }, Containers: []v1.Container{ { SecurityContext: &v1.SecurityContext{ <del> RunAsUser: utilptr.Int64Ptr(1000), </del> <ins> RunAsUser: ptr.To[int64](1000), </ins> }, }, {

projected volumes exclude ephemeral containers in calculating fs user because "SecurityContext is not allowed" : This is no longer technically correct -- ephemeral containers are allowed to specify security context -- but it's a no-op because is guaranteed to be empty at pod creation when fs user is calculated. Still, the comment is wrong so let's clean it up to avoid confusion. /kind cleanup
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 storage /assign
/priority backlog
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
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-lifecycle rotten


Question: t.Errorf("expected success, got %q", err) continue } else if err == nil && tc.success == false { <del> t.Errorf("expected failure") </del> <ins> t.Errorf("expected failure %#v", testCases[i]) </ins> continue } else if tc.success { if f.String() != tc.expected {

<!-- 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 feature What happened: Implement this TODO: What you expected to happen: Start kube-proxy with a 'beginPort+offset' format port range configuration. This is needed when I want to allocate specific numbers of port from a host without extra manual calculation. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
/sig network Does anyone besides kube-proxy use this?
/assign


Question: toContain("found no matching overload for 'allowed' applied to 'kubernetes.authorization.Authorizer"), }, }, <ins> { name: "variables valid", policy: &v1beta1.ValidatingAdmissionPolicy{Spec: v1beta1.ValidatingAdmissionPolicySpec{ Variables: []v1beta1.Variable{ { Name:       "works", Expression: "true", }, }, Validations: []v1beta1.Validation{ { Expression: "variables.works", }, }, MatchConstraints: deploymentPolicy.Spec.MatchConstraints, }, }, schemaToReturn: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "foo": *spec.Int64Property(), }, }, }, assertions: []assertionFunc{toHaveLengthOf(0)}, }, { name: "variables missing field", policy: &v1beta1.ValidatingAdmissionPolicy{Spec: v1beta1.ValidatingAdmissionPolicySpec{ Variables: []v1beta1.Variable{ { Name:       "works", Expression: "true", }, }, Validations: []v1beta1.Validation{ { Expression: "variables.nonExisting", }, }, MatchConstraints: deploymentPolicy.Spec.MatchConstraints, }, }, schemaToReturn: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "foo": *spec.Int64Property(), }, }, }, assertions: []assertionFunc{ toHaveLengthOf(1), toHaveFieldRef("spec.validations[0].expression"), toContain("undefined field 'nonExisting'"), }, }, { name: "variables field wrong type", policy: &v1beta1.ValidatingAdmissionPolicy{Spec: v1beta1.ValidatingAdmissionPolicySpec{ Variables: []v1beta1.Variable{ { Name:       "name", Expression: "'something'", }, }, Validations: []v1beta1.Validation{ { Expression: "variables.name == object.foo", // foo is int64 }, }, MatchConstraints: deploymentPolicy.Spec.MatchConstraints, }, }, schemaToReturn: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "foo": *spec.Int64Property(), }, }, }, assertions: []assertionFunc{ toHaveLengthOf(1), toHaveFieldRef("spec.validations[0].expression"), toContain("found no matching overload for '_==_' applied to '(string, int)"), }, }, { name: "error in variables, not reported during type checking.", policy: &v1beta1.ValidatingAdmissionPolicy{Spec: v1beta1.ValidatingAdmissionPolicySpec{ Variables: []v1beta1.Variable{ { Name:       "name", Expression: "object.foo == 'str'", }, }, Validations: []v1beta1.Validation{ { Expression: "variables.name == object.foo", // foo is int64 }, }, MatchConstraints: deploymentPolicy.Spec.MatchConstraints, }, }, schemaToReturn: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "foo": *spec.Int64Property(), }, }, }, assertions: []assertionFunc{ toHaveLengthOf(0), }, }, </ins> } { t.Run(tc.name, func(t *testing.T) { typeChecker := buildTypeChecker(tc.schemaToReturn)

When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted


Question: "time" "github.com/google/go-cmp/cmp" <ins> "github.com/google/go-cmp/cmp/cmpopts" </ins> "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require"

pull-kubernetes-unit dynamicresources unknown multiple failures in tests as seen in n/a /sig scheduling
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
probably cc
/assign
DeepCopy missing here:


Question: ginkgo.It("test Deployment ReplicaSet orphaning and adoption regarding controllerRef", func() { testDeploymentsControllerRef(f) }) <del> ginkgo.It("Deployment should have a working scale subresource", func() { </del> <ins> /* Release: v1.21 Testname: Deployment, completes the scaling of a Deployment subresource Description: Create a Deployment with a single Pod. The Pod MUST be verified that it is running. The Deployment MUST get and verify the scale subresource count. The Deployment MUST update and verify the scale subresource. The Deployment MUST patch and verify a scale subresource. */ framework.ConformanceIt("Deployment should have a working scale subresource", func() { </ins> testDeploymentSubresources(f) }) /*

[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. with this query you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a Deployment with a static label Read the Deployment Update the DeploymentScale Get the DeploymentScale to ensure it is updated Patch the DeploymentScale Read the DeploymentScale to ensure it is Patch Delete the Namespace and Deployment Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource readAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource replaceAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by N points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Issue was presented in the Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints, and this issue was created for that purpose.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details