Question: RestartPolicy: v1.RestartPolicyOnFailure, }, } <ins> if podConfig.PodFSGroupChangePolicy != nil { podSpec.Spec.SecurityContext.FSGroupChangePolicy = podConfig.PodFSGroupChangePolicy } </ins> var volumeMounts = make([]v1.VolumeMount, 0) var volumeDevices = make([]v1.VolumeDevice, 0) var volumes = make([]v1.Volume, len(podConfig.PVCs)+len(podConfig.InlineVolumeSources))

We need to add e2e that verifies volume permissions in pod with different values of fsGroupChangePolicy. /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
/assign


Question: set -o pipefail IFS=$'nt' <del> SCRIPT_DIR=$(cd $(dirname $0); pwd) </del> <ins> SCRIPT_DIR=$(CDPATH="" cd $(dirname $0); pwd) </ins> INSTANCE_PREFIX=$1

What happened: If an in-tree volume is provisioned with in-tree provisioner (without migration enabled) and later migration gets enabled, the PV controller is expected to coordinate with the CSI external provisioner to make sure it does get deleted. For above to happen, this in the PV controller needs to return nil, nil even if is set to a plugin prefixed with . The CSI external provisioner also needs to be enhanced to delete PV's whose is set to a plugin prefixed with . We also need to prevent a race between external provisioner and in-tree PV controller in the delete path when CSI Migration flag is disabled. To achieve this synchronization, PV controller will need to mark the in-tree PVs that need to be deleted by external provisioner with an additional annotation to signal that CSI Migration flag is enabled in-tree and the CSI external provisioner needs to process the deletion. What you expected to happen: CSI driver should process the deletion. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.15 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:
/assign
/sig storage
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
Instead of this would it be possible to just change the annotation on the . That is the signal. Otherwise we run the risk of adding yet another condition to the already complex logic. I wonder if its possible to have the PV controller go in and switch them all on when it detects is on.
cc
This is a high priority to be fixed and should be cherry-picked as well if possible
I'd like to raise the priority for this one as well, especially after the explicit end-user ask for migration to CSI (for AWS EBS and GCE PD, at least) in the official 1.17.0 release notes.

IMO it's not possible to migrate because deletion of PVs created before CSI migration does not work due to this bug. See also:
/open no current released versions of Kubernetes or External-provisioner where this is fixed. Likely to be and
/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
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


Question: expectNotFound: true, }, { <ins> cidr:           "172.17.0.2/32", output:         tcFilterOutputNewVersion, expectedClass:  "1:1", expectedHandle: "800::800", }, { cidr:           "1.2.3.4/16", output:         tcFilterOutputNewVersion, expectedClass:  "1:2", expectedHandle: "800::801", }, { cidr:           "2.2.3.4/16", output:         tcFilterOutputNewVersion, expectNotFound: true, }, { </ins> err:       errors.New("test error"), expectErr: true, },

What happened: I tried to set up bandwidth limiting by booting a cluster with , which by default sets up kubenet. I used the annotations xM xM and then used to test the ingress and egress bandwidths, with no effect. Does anyone know if this feature is still supported in kubenet? And if so what are the steps I need to take to boot a cluster that can use pod annotations to do tc shaping. What you expected to happen: Per traffic shaping should be implemented on Kubenet as of 4/12/2018. Anything else we need to know?: There are a lot of issues regarding traffic shaping not working. None have a concrete answer of how to get it to work on kubenet: Relevant: I believe this is where it was first implemented. Environment: Kubernetes version (use ): 1.11.8 Cloud provider or hardware configuration: AWS CC:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
/triage unresolved I am a bot run by
can we put this on sig-network agenda? the discussion item would be: what is the current status of this feature (alpha, beta, GA?) what should we do next with this API?
I have this to the agenda, will grab some info.
AFAIK traffic shaping is still supported in kubenet. Does a pod with these annotations come up successfully but has no traffic shaping applied? Or do things fail earlier? If it comes up successfully, could you run ?
On GKE we do not officially support this, our default image even don't have tc installed. I tried with ubuntu, the kubenet is failed to parse the tc output. kubenet expect. // filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 tc return.// filter parent 1: protocol ip pref 1 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 notinhw
If this issue has been triaged, please comment .

Meta: /athenabot mark-triage-reminder I am a bot run by
Depending on which CNI plugin you use you need to install the bandwidth plugin, see:
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
since it is in progress /priority critical-urgent /milestone v1.17
/lifecycle frozen
/assign
Bug triage for release 1.17 here. Since this issue has been tagged for the milestone, we would like to check it's status. Code freeze is on Nov. 14. Will this issue be resolved before then? If not, we should move it out of the milestone.
The fix is still pending in review.
Will it be merged by this Thursday for v1.17 code freeze?
/milestone v1.18 (v1.17 code freeze)
matching assigned priority on PR
Hello I'm one of the Bug Triage shadows for the 1.18 release. Since this issue is tagged for 1.18, I'd like to check its status. Is this issue intended for milestone 1.18? Friendly reminder: Code freeze is scheduled for March 5th.
Hello Checking in again. Do you think this will make it in for 1.18 release?
Hey Checking in again as this issue is marked as . Are you close to completing this for v1.18 release? Another reminder that code freeze is just around the corner! (March 5th).
Friendly reminder that code freeze is in 2 days and this issue is marked as
The fix got approved by ,should be able to catch the freeze.


Question: result = append(result, schedulerapi.HostPriority{Host: node, Score: int(fScore)}) } // add the open nodes with a score of 0 <del> for _, node := range otherNodes { </del> <ins> for _, node := range nonLabeledNodes { </ins> result = append(result, schedulerapi.HostPriority{Host: node, Score: 0}) } return result, nil }

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Kubernetes version (use ): master What happened: The functionality is hidden in a large function, and not explicit, testable. What you expected to happen: The logic of should read more clearly, with tests for individual filters.
has a PR for this .
Few more things include removing limits in entries like
yeah, im not sure why the thing is there, after all they are just appending to the slice and the limit wont have an effect , from what i can tell, will it? probably good idea to remove unless im missing something.
Its part of part of PR too.


Question: t.Fatalf("Unexpected error getting claimRef: %v", err) } pv.Spec.ClaimRef = claimRef <ins> pv.Spec.ClaimRef.UID = "" </ins> pv, err = testClient.PersistentVolumes().Create(pv) if err != nil { t.Fatalf("Unexpected error creating pv: %v", err) } <ins> glog.V(2).Infof("TestPersistentVolumeBindRace pv created, pre-bound to %s", claim.Name) </ins> waitForPersistentVolumePhase(testClient, pv.Name, watchPV, api.VolumeBound) <ins> glog.V(2).Infof("TestPersistentVolumeBindRace pv bound") </ins> waitForAnyPersistentVolumeClaimPhase(watchPVC, api.ClaimBound) <ins> glog.V(2).Infof("TestPersistentVolumeBindRace pvc bound") </ins> pv, err = testClient.PersistentVolumes().Get(pv.Name) if err != nil {

Test failed with and the relevant part of the stack trace is: Logs:
(or anyone), integration tests do not log much and I don't know what's going on in volume controller. Would it be possible to raise integration test log level at least to v=3 (4 preferred)?
what is the status of
can you please take a look?
Increasing integration log level can go into I think. It's probably a good idea to split them into their own job.


Question: resourcev1alpha2 "k8s.io/api/resource/v1alpha2" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/labels" </ins> "k8s.io/client-go/kubernetes" "k8s.io/dynamic-resource-allocation/controller" "k8s.io/klog/v2" "k8s.io/kubernetes/test/e2e/dra/test-driver/app" "k8s.io/kubernetes/test/e2e/framework" <ins> e2enode "k8s.io/kubernetes/test/e2e/framework/node" </ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" admissionapi "k8s.io/pod-security-admission/api" utilpointer "k8s.io/utils/pointer"

We need to explore how DRA interacts with One likely outcome is that the DRA helper code watches for nodes with the special label and helps DRA drivers clean up. /sig node
/assign
/triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage important-soon as this is a DRA Beta criteria and DRA is going to be graduated to Beta in 1.29 Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Here's a test that was written for volumes:
Thank you. I’ve found it last week. Unfortunately kind image doesn’t have ssh, so stopping kubelet is not possible the way this test does. I’ve found another solution.
I was able to simulate non-graceful node shutdown by running . It turned out that after adding tent, all node pods are deleted by the GC controller and the resource claim controller successfully deallocated the resource. So, it looks like a non-graceful shutdown is handled correctly and no code changes are required. However, the fact that can potentially be called without calling should be explained in the DRA KEP, so that DRA plugin authors will be aware of this. I'll add an explanation of handling non-graceful node shoutdown to the and add a correspondent e2e test case to the DRA e2e test suite.
KEP update PR: E2E PR:


Question: func (csiNodeStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList { newCSINodeObj := obj.(*storage.CSINode) oldCSINodeObj := old.(*storage.CSINode) <del> // in 1.22 on update, set AllowLongNodeID to true only if the old object already has a long node ID // in 1.23 on update, set AllowLongNodeID=true allowLongNodeID := false for _, nodeDriver := range oldCSINodeObj.Spec.Drivers { if validation.CSINodeLongerID(nodeDriver.NodeID) { allowLongNodeID = true } } </del> validateOptions := validation.CSINodeValidationOptions{ <del> AllowLongNodeID: allowLongNodeID, </del> <ins> AllowLongNodeID: true, </ins> } errorList := validation.ValidateCSINode(newCSINodeObj, validateOptions)

will be used as a preparation for relaxing CSI Node id length limitation, in 1.22, we need to make sure the AllowLongNodeID is set correctly according to the comment /sig storage /assign /cc
/milestone 1.22
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone 1.22 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
Can you make a better title - I almost jumped out of my skin :)
Oops, sorry about that lol
/triage accepted
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]:


Question: return proxyModeUserspace } <ins> func detectNumCPU() int { return goruntime.NumCPU() } </ins> func tryWinKernelSpaceProxy(kcompat winkernel.KernelCompatTester) string { // Check for Windows Kernel Version if we can support Kernel Space proxy // Check for Windows Version

A new flag indicating how kube-proxy gets the number of CPUs, either from goruntime or . In kube-proxy, we can use to set node's , the resulting is . We have nodes where pods with none CPU policy and static CPU policy are running together. Pods like kube-proxy are running in none CPU policy by default, and they only gets CPUs left by static CPU policy pods. If static CPU policy pods take away most CPUs cores, kube-proxy can only get one or two cores, then will be set to a very small values. In this case, a lot packet failure can occur. When we set kube-proxy to work in static CPU policy, kube-proxy only gets the number of CPUs selected by the CPU policy, not the number of total CPUs on the node. This may surprise users who are only trying to limit kube-proxy's CPU usages, but resulting in some conntrack fulls faults. Please let me know if this enhancement is reasonable, so I can send a pr later. Thanks!
/sig network
Is it refer to deploy order of kube-proxy? If kube-proxy deploy first in node, will it get just one or two core?
By one or two I mean kube-proxy gets a small number of CPU cores, because most of CPU cores are allocated to static policy pods, sorry for the misunderstanding. The number of conntrack-max depends on the CPU cores when kube-proxy started, even kube-proxy was first deployed, it can get restarted or redeployed by some reasons. Then the conntrack-max will change.
yeah, when kube-proxy deploy firstly, Maybe it can see the whole cpu nums from shared cpu(/var/lib/kubelet/cpumanagestate when kubelet start with static cpu policy). But I think it is a bug for kube-proxy. The cpu info can also get from node resource info. So will it be suitable to add a flag to set cpu num?
Maybe, or we can add a flag for user to choose where kube-proxy should get CPU informations from. There maybe some multi-tenant scenarios where kube-proxy are deployed for per tenant so they would like to limit conntrack-max by CPU cores allocated to each tenant.
I think the simple fix is to replace with something that counts /proc/cpuinfo. I don't know of anyone running multiple proxies, and I don't think it would work well. The intention was "all the CPUs on the node". PRs welcome!
/triage accepted


Question: <ins> #!/bin/bash # 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. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. source "${KUBE_ROOT}/hack/lib/util.sh" CLEAN_PATTERNS=( "_tmp" "doc_tmp" ".*/zz_generated.openapi.go" "test/e2e/generated/bindata.go" ) for pattern in ${CLEAN_PATTERNS[@]}; do for match in $(find "${KUBE_ROOT}" -iregex "^${KUBE_ROOT}/${pattern}$"); do echo "Removing ${match#${KUBE_ROOT}/} .." rm -rf "${match#${KUBE_ROOT}/}" done done # ex: ts=2 sw=2 et filetype=sh </ins>

Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: After setting up an IntelliJ project files for the Kubernetes repo, I had IntelliJ related project files in the directory. Wanting to clean up some generated files, I ran . I was surprised to see that my IntelliJ project files were deleted as well. What you expected to happen: I would have expected to remove only files generated by kubernetes development commands. I would not have expected it to not delete files that I created and intended to be long-lasting, but were only usable by me, and thus gitignored. How to reproduce it (as minimally and precisely as possible): Create a IntelliJ project for Kubernetes that places or files in the repo. Run . The IntelliJ project will be deleted. Anything else we need to know?: I'm not entirely ensure what the correct behavior is here. I see the change to use was made recently by in this . The reasons stated in the pr make a lot of sense to me. However, I think this doesn't cover the edge case in which a file is gitignored because it should be long-lasting and it will be unique to each development environment, and thus should not be removed on every . I'd love to work on figuring out the proper behavior here, and submitting a pr to fix - please let me know how I can help :)
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig contributor-experience
I'd be interested if you have any suggestions of what to do here. There's a few file system workarounds (such as having your dir outside of the project and symlinking it in.. then you'd just have to restore the symlink after a . I think it's more the assumption that it would only remove build artifacts, rather than removing all temp/.gitignored files.
I'm not super unfamiliar with idiomatic files, so part of this may be my misunderstanding.

My assumption was would remove artifacts that could've been created by some make command (i.e. ). I wouldn't have assumed it would remove all files. What about having a which only removes files generated by and then a (or or ) which removes any gitignored files? Thanks for your help with this :)
Agree on should only remove those things it created by itself (can be any make sub-commands in Makefile). It'd better not remove other files (even if they're untracked) which may be created by users or user tools. Maybe we can create a blacklist file which includes those things created by and should be removed by .
that sounds like a good plan to me - what would you think of that is a fix? My understanding is that that would be similar to what was in place before, except before the list was missing artifacts we wanted to remove.
I think it's just a difference in assumption around what the command does. When I run "make clean" I want to ensure that that my working copy doesn't have any files that may change or interfere with a build. To me, this is any files we don't check into the repo. Maintaining a list of files that is safe to clean leaves us open to the list falling out of date (which it previously did, which is why the functionality was changed in the first place).
Yeah, I think you make a great point that it seems like there are two different interpretations of what does. I'm not super familiar with - do you know which one is the more "traditional" interpretation? One thing I think about is that it seems slightly more dangerous to delete too many, instead of too few files - one operation is very easy to address, whereas the other isn't. I think that leads me to prefer a slightly less aggressive . Thoughts on if it would be helpful for me to write a pr so we have some concrete code to base this chat on?
My opinion is that deletes only things that were generated by something did. If I want to delete other files I created, I call instead.
oh, but we're using , which only deletes ignored files. that's better, though still potentially unexpected.
I created a with an optional different implementation so we could have something to compare the current behavior too.

Let me know your thoughts :)
IMO, The point of moving to using was that anything in your dir that isn't a part of the checked in repo has the potential to impact the build. Temp files, generated files, _output directories, etc. The previous functionality maintained a smaller, manual list that did become out of date (not just in theory), and caused problems. I'm open to solutions, but I don't feel great about returning to a manual list as that's what broke things in the first place.
You make a great point about the manual white list becoming out of date - and I think its particularly convincing that that's happened in practice. I have two ideas: you think that having two options - and - like in the diff - helps address this? The typical developer can use on their local system, while automated processes creating builds can use ? , what if instead of having a whitelist of files to delete, we had a blacklist of files not to delete? This solves the issue which caused me to report this "bug" and the potential drift of the blacklist seems much less concerning. Do either of those sound preferable? If so, I'll update my pr. Thanks for your thought on this :)
I believe this is a bug introduced by , therefore mark this as a bug instead of feature. etcd will also be removed by , which isn't right. cc
where is the local etcd being stored? do you have details on the bug?
Are you talking about builds that take place outside of a docker container (or bazel sandbox)? I don't think we should offer any guarantees about getting a good build outside of docker or a bazel sandbox. If our containerized build is pulling in the wrong files, though, it seems we could fix that by writing code that is more specific about what it includes.
Yeah this is a terrible thing to do to people, I have all sorts of stuff in some of my kubernetes directories that I would not be happy if make clean obliterated.
I have dozens of utility shell scripts and example yaml files that are ignored via . I lost all of them after T_T
etcd installed by hack/install- is in .gitignore too, and therefore gets deleted by :
Got it. Yeah, that's a problem. I opened to move to a back to a static list of files to clean.

It is more correct than a revert as it adds missing patterns, and it's safer than an .


Question: test/e2e/network/service.go: "should be able to change the type from ExternalName to NodePort" test/e2e/network/service.go: "should be able to change the type from ClusterIP to ExternalName" test/e2e/network/service.go: "should be able to change the type from NodePort to ExternalName" <ins> test/e2e/network/service.go: "should find a service from listing all namespaces" </ins> test/e2e/network/service_latency.go: "should not be very high" test/e2e/node/events.go: "should be sent by kubelets and the scheduler about pods scheduling and running" test/e2e/node/pods.go: "should be set on Pods with matching resource requests and limits for memory and cpu"

This issue proposes the writing of a new test for the API endpoint with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. There are no tests listing services, see the following: This mock test uses client-go's functions and hits the endpoints. This shows the endpoints hit by my approach: /sig architecture /area conformance


Question: github.com/coreos/go-oidc v2.2.1+incompatible github.com/coreos/go-systemd/v22 v22.5.0 github.com/cpuguy83/go-md2man/v2 v2.0.2 <del> github.com/cyphar/filepath-securejoin v0.2.3 </del> <ins> github.com/cyphar/filepath-securejoin v0.2.4 </ins> github.com/distribution/reference v0.5.0 github.com/docker/go-units v0.5.0 github.com/emicklei/go-restful/v3 v3.9.0

One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
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 security
/kind bug /sig security


Question: }, "topologyKey": { "type": "string", <del> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed." </del> <ins> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed." </ins> } } },

The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.


Question: grabFromScheduler                 bool grabFromClusterAutoscaler         bool kubeScheduler                     string <ins> waitForSchedulerReadyOnce         sync.Once </ins> kubeControllerManager             string waitForControllerManagerReadyOnce sync.Once }

! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig instrumentation /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The flake happened in before.
This is fixed. !
/reopen This is still failing. Sample run:
Reopened this issue. <detailsIn response to : /reopen Sample run: Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority critical-urgent
The error message in makes me think the apiserver is not available during that test run: . Can someone link to the frequency graphs to see if the problem is widespread?
got it:
I don't think I was right above. I think the "the server is currently unable to handle the request" is an error coming from the proxy. The proxy was around the time this issue was filed (), so it seems likely to be related to it. can you take a look?
This is a known issue, and is working on it . Now that is being blocked by the debugging handler problem, could we merge to mitigate this problem first? cc
I would prefer to reach a decision about enabling the debug handlers, but if that's not possible, then merging PR as mitigation might make sense.
Think I hit this also.
It appears to still be failing based on
Why rebase? Any new test run will be based on merge with current k/k master and thus contain
<img width="1111" alt="Screen Shot 2021-05-28 at 13 04 52" src="https://user-" looks like it has become more stable now.
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: import ( "encoding/json" "fmt" <del> "runtime" </del> <ins> "math/rand" </ins> "strconv" "testing" "time"

Have not reproduced locally even after a few tens of runs.
which version of Go are you using locally? This probably only repros on 1.5.1.
This was from Jenkins runs.
This is caused because an attempts counter is being read/written to without synchronization. I think this is caused by the event creation order not being guaranteed. I am looking a little deeper to track this down.
Got a fix with 130k+ runs and no failures. Will send out PR shortly.


Question: func TestActivePodFiltering(t *testing.T) { logger, _ := ktesting.NewTestContext(t) <del> // This rc is not needed by the test, only the newPodList to give the pods labels/a namespace. rc := newReplicationController(0) podList := newPodList(nil, 5, v1.PodRunning, rc) podList.Items[0].Status.Phase = v1.PodSucceeded podList.Items[1].Status.Phase = v1.PodFailed expectedNames := sets.NewString() for _, pod := range podList.Items[2:] { expectedNames.Insert(pod.Name) </del> <ins> type podData struct { podName  string podPhase v1.PodPhase </ins> } <del> var podPointers []*v1.Pod for i := range podList.Items { podPointers = append(podPointers, &podList.Items[i]) </del> <ins> type test struct { name         string pods         []podData wantPodNames []string </ins> } <del> got := FilterActivePods(logger, podPointers) gotNames := sets.NewString() for _, pod := range got { gotNames.Insert(pod.Name) </del> <ins> tests := []test{ { name: "Filters active pods", pods: []podData{ {podName: "pod-1", podPhase: v1.PodSucceeded}, {podName: "pod-2", podPhase: v1.PodFailed}, {podName: "pod-3"}, {podName: "pod-4"}, {podName: "pod-5"}, }, wantPodNames: []string{"pod-3", "pod-4", "pod-5"}, }, </ins> } <del> if diff := cmp.Diff(expectedNames.List(), gotNames.List()); diff != "" { t.Errorf("Active pod names (-want,+got):n%s", diff) </del> <ins> for _, test := range tests { t.Run(test.name, func(t *testing.T) { // This rc is not needed by the test, only the newPodList to give the pods labels/a namespace. rc := newReplicationController(0) podList := newPodList(nil, 5, v1.PodRunning, rc) for idx, testPod := range test.pods { podList.Items[idx].Name = testPod.podName podList.Items[idx].Status.Phase = testPod.podPhase } var podPointers []*v1.Pod for i := range podList.Items { podPointers = append(podPointers, &podList.Items[i]) } got := FilterActivePods(logger, podPointers) gotNames := sets.NewString() for _, pod := range got { gotNames.Insert(pod.Name) } if diff := cmp.Diff(test.wantPodNames, gotNames.List()); diff != "" { t.Errorf("Active pod names (-want,+got):n%s", diff) } }) </ins> } } func TestSortingActivePods(t *testing.T) { <del> numPods := 9 // This rc is not needed by the test, only the newPodList to give the pods labels/a namespace. rc := newReplicationController(0) podList := newPodList(nil, numPods, v1.PodRunning, rc) pods := make([]*v1.Pod, len(podList.Items)) for i := range podList.Items { pods[i] = &podList.Items[i] } // pods[0] is not scheduled yet. pods[0].Spec.NodeName = "" pods[0].Status.Phase = v1.PodPending // pods[1] is scheduled but pending. pods[1].Spec.NodeName = "bar" pods[1].Status.Phase = v1.PodPending // pods[2] is unknown. pods[2].Spec.NodeName = "foo" pods[2].Status.Phase = v1.PodUnknown // pods[3] is running but not ready. pods[3].Spec.NodeName = "foo" pods[3].Status.Phase = v1.PodRunning // pods[4] is running and ready but without LastTransitionTime. </del> now := metav1.Now() <del> pods[4].Spec.NodeName = "foo" pods[4].Status.Phase = v1.PodRunning pods[4].Status.Conditions = []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue}} pods[4].Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}} // pods[5] is running and ready and with LastTransitionTime. pods[5].Spec.NodeName = "foo" pods[5].Status.Phase = v1.PodRunning pods[5].Status.Conditions = []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: now}} pods[5].Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}} // pods[6] is running ready for a longer time than pods[5]. </del> then := metav1.Time{Time: now.AddDate(0, -1, 0)} <del> pods[6].Spec.NodeName = "foo" pods[6].Status.Phase = v1.PodRunning pods[6].Status.Conditions = []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}} pods[6].Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}} // pods[7] has lower container restart count than pods[6]. pods[7].Spec.NodeName = "foo" pods[7].Status.Phase = v1.PodRunning pods[7].Status.Conditions = []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}} pods[7].Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: 2}, {RestartCount: 1}} pods[7].CreationTimestamp = now // pods[8] is older than pods[7]. pods[8].Spec.NodeName = "foo" pods[8].Status.Phase = v1.PodRunning pods[8].Status.Conditions = []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}} pods[8].Status.ContainerStatuses = []v1.ContainerStatus{{RestartCount: 2}, {RestartCount: 1}} pods[8].CreationTimestamp = then getOrder := func(pods []*v1.Pod) []string { names := make([]string, len(pods)) for i := range pods { names[i] = pods[i].Name } return names </del> <ins> tests := []struct { name      string pods      []v1.Pod wantOrder []string }{ { name: "Sorts by active pod", pods: []v1.Pod{ { ObjectMeta: metav1.ObjectMeta{Name: "unscheduled"}, Spec:       v1.PodSpec{NodeName: ""}, Status:     v1.PodStatus{Phase: v1.PodPending}, }, { ObjectMeta: metav1.ObjectMeta{Name: "scheduledButPending"}, Spec:       v1.PodSpec{NodeName: "bar"}, Status:     v1.PodStatus{Phase: v1.PodPending}, }, { ObjectMeta: metav1.ObjectMeta{Name: "unknownPhase"}, Spec:       v1.PodSpec{NodeName: "foo"}, Status:     v1.PodStatus{Phase: v1.PodUnknown}, }, { ObjectMeta: metav1.ObjectMeta{Name: "runningButNotReady"}, Spec:       v1.PodSpec{NodeName: "foo"}, Status:     v1.PodStatus{Phase: v1.PodRunning}, }, { ObjectMeta: metav1.ObjectMeta{Name: "runningNoLastTransitionTime"}, Spec:       v1.PodSpec{NodeName: "foo"}, Status: v1.PodStatus{ Phase:             v1.PodRunning, Conditions:        []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue}}, ContainerStatuses: []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}}, }, }, { ObjectMeta: metav1.ObjectMeta{Name: "runningWithLastTransitionTime"}, Spec:       v1.PodSpec{NodeName: "foo"}, Status: v1.PodStatus{ Phase:             v1.PodRunning, Conditions:        []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: now}}, ContainerStatuses: []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}}, }, }, { ObjectMeta: metav1.ObjectMeta{Name: "runningLongerTime"}, Spec:       v1.PodSpec{NodeName: "foo"}, Status: v1.PodStatus{ Phase:             v1.PodRunning, Conditions:        []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}}, ContainerStatuses: []v1.ContainerStatus{{RestartCount: 3}, {RestartCount: 0}}, }, }, { ObjectMeta: metav1.ObjectMeta{Name: "lowerContainerRestartCount", CreationTimestamp: now}, Spec:       v1.PodSpec{NodeName: "foo"}, Status: v1.PodStatus{ Phase:             v1.PodRunning, Conditions:        []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}}, ContainerStatuses: []v1.ContainerStatus{{RestartCount: 2}, {RestartCount: 1}}, }, }, { ObjectMeta: metav1.ObjectMeta{Name: "oldest", CreationTimestamp: then}, Spec:       v1.PodSpec{NodeName: "foo"}, Status: v1.PodStatus{ Phase:             v1.PodRunning, Conditions:        []v1.PodCondition{{Type: v1.PodReady, Status: v1.ConditionTrue, LastTransitionTime: then}}, ContainerStatuses: []v1.ContainerStatus{{RestartCount: 2}, {RestartCount: 1}}, }, }, }, wantOrder: []string{ "unscheduled", "scheduledButPending", "unknownPhase", "runningButNotReady", "runningNoLastTransitionTime", "runningWithLastTransitionTime", "runningLongerTime", "lowerContainerRestartCount", "oldest", }, }, </ins> } <del> expected := getOrder(pods) </del> <ins> for _, test := range tests { t.Run(test.name, func(t *testing.T) { numPods := len(test.pods) </ins> <del> for i := 0; i < 20; i++ { idx := rand.Perm(numPods) randomizedPods := make([]*v1.Pod, numPods) for j := 0; j < numPods; j++ { randomizedPods[j] = pods[idx[j]] } sort.Sort(ActivePods(randomizedPods)) actual := getOrder(randomizedPods) </del> <ins> for i := 0; i < 20; i++ { idx := rand.Perm(numPods) randomizedPods := make([]*v1.Pod, numPods) for j := 0; j < numPods; j++ { randomizedPods[j] = &test.pods[idx[j]] } </ins> <del> assert.EqualValues(t, expected, actual, "expected %v, got %v", expected, actual) </del> <ins> sort.Sort(ActivePods(randomizedPods)) gotOrder := make([]string, len(randomizedPods)) for i := range randomizedPods { gotOrder[i] = randomizedPods[i].Name } if diff := cmp.Diff(test.wantOrder, gotOrder); diff != "" { t.Errorf("Sorted active pod names (-want,+got):n%s", diff) } } }) </ins> } }

During implementation of KEP 3393 (PodReplacementPolicy for Jobs) we found that the unit tests of do not follow common patterns established in k/k. 1) The tests are not written using table driven design (). 2) The tests use rather than . This probably should be done as two separate PRs but wanted to highlight some areas that could use some cleanup. Not using means that we don't see diffs in the unit tests that makes this difficult. And not using table driven tests makes it difficult to add new test cases as it usually is brought up during review that we should use a table-driven test but the entire file does not obey this format.
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 apps /kind cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig apps /kind cleanup /help /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'd like to work on it /assign
I'd also like to make some contributions. /assign
Looks like this need two PRs. tests are not written using table driven design (). tests use Differences rather than Cmp.Diff. I think I can work on the 2nd one and leave the 1st one to you.

Sounds good?
By looking through the , I found the main function to comapre the results have already used cmp.Diff. Can you elaborate more on which part you expect to use cmp.Diff? func verifyDeletedAndPatchedPods(t testing.T, client fake.Clientset, wantDeletedPodNames, wantPatchedPodNames sets.String) { t.Helper() deletedPodNames := getDeletedPodNames(client) if diff := cmp.Diff(wantDeletedPodNames, deletedPodNames); diff != "" { t.Errorf("Deleted pod names (-want,+got):n%s", diff) } patchedPodNames := getPatchedPodNames(client) if diff := cmp.Diff(wantPatchedPodNames, patchedPodNames); diff != "" { t.Errorf("Patched pod names (-want,+got):n%s", diff) } }
I am really sorry about this. Too much multitasking!! I meant not
Hey ! Sorry, I didn't see this before. No problem at all, but consider that one change depends on the other, and since my task implies a big refactor, there might be conflicts when merging your PR... That's why I see two possible scenarios happening: Your PR gets merged before I raise mine: Then fine, I'll rebase your changes and adapt my code Mine is ready before yours is merged: In this case, I propose you commit your changes to my PR. Both of us will appear as coauthors of the change Getting a PR merged in the Kubernetes project takes quite some time (trust me, I talk by experience and can confirm ) WDYT?
Let's see how it goes. We can always rebase the code change to adapt new.
btw, did you already begin to work on task 1? If not, I may just go ahead and work on it right away since I have already dig into it.
yes, I already started And If you ask me, better to keep it this way so we both have an opportunity to have a contribution
cool. Sounds good.
/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
Hi if this issue needs to be worked on any further, please assign me for the same.
has a PR up that will solve the second part of this issue.


Question: } // errEmptyName is returned when API requests do not fill the name section of the path. <del> var errEmptyName = fmt.Errorf("name must be provided") </del> <ins> var errEmptyName = errors.NewBadRequest("name must be provided") </ins> // Installs handlers for API resources. func (a *APIInstaller) Install() (ws *restful.WebService, errors []error) {

e.g. REST.Update should never return an arbitrary error value. Maybe we should change the return code to something stricter than generic error.
/cc
FYI: is for remaining cases where the API doesn't return JSON/Status errors.
Re-opening this until we
I think etcd errors require more abstraction, also:
There are some admission control plugins that did not always follow that practice which I will resolve as part of
Are there any known instances of this remaining?
None that I know of.


Question: framework.Failf("failed to get back the correct deleted flunders list %v from the dynamic client", unstructuredList) } <ins> ginkgo.By("Recreating test-flunder before removing endpoint via deleteCollection") jsonFlunder, err = json.Marshal(testFlunder) framework.ExpectNoError(err, "marshalling test-flunder for create using dynamic client") unstruct = &unstructured.Unstructured{} err = unstruct.UnmarshalJSON(jsonFlunder) framework.ExpectNoError(err, "unmarshalling test-flunder as unstructured for create using dynamic client") _, err = dynamicClient.Create(ctx, unstruct, metav1.CreateOptions{}) framework.ExpectNoError(err, "listing flunders using dynamic client") // kubectl get flunders unstructuredList, err = dynamicClient.List(ctx, metav1.ListOptions{}) framework.ExpectNoError(err, "listing flunders using dynamic client") if len(unstructuredList.Items) != 1 { framework.Failf("failed to get back the correct flunders list %v from the dynamic client", unstructuredList) } ginkgo.By("Read v1alpha1.wardle.example.com /status before patching it") statusContent, err = restClient.Get(). AbsPath("/apis/apiregistration.k8s.io/v1/apiservices/v1alpha1.wardle.example.com/status"). SetHeader("Accept", "application/json").DoRaw(ctx) framework.ExpectNoError(err, "No response for .../apiservices/v1alpha1.wardle.example.com/status. Error: %v", err) wardle.Reset() err = json.Unmarshal([]byte(statusContent), &wardle) framework.ExpectNoError(err, "Failed to process statusContent: %v | err: %v ", string(statusContent), err) ginkgo.By("Patch APIService Status") patch := map[string]interface{}{ "status": map[string]interface{}{ "conditions": append(wardle.Status.Conditions, apiregistrationv1.APIServiceCondition{ Type:    "StatusPatched", Status:  "True", Reason:  "E2E", Message: "Set by e2e test", }), }, } payload, err := json.Marshal(patch) framework.ExpectNoError(err, "Failed to marshal JSON. %v", err) _, err = restClient.Patch(types.MergePatchType). AbsPath("/apis/apiregistration.k8s.io/v1/apiservices/v1alpha1.wardle.example.com/status"). SetHeader("Accept", "application/json"). Body([]byte(payload)). DoRaw(ctx) framework.ExpectNoError(err, "Patch failed for .../apiservices/v1alpha1.wardle.example.com/status. Error: %v", err) ginkgo.By("Confirm that v1alpha1.wardle.example.com /status was patched") statusContent, err = restClient.Get(). AbsPath("/apis/apiregistration.k8s.io/v1/apiservices/v1alpha1.wardle.example.com/status"). SetHeader("Accept", "application/json").DoRaw(ctx) framework.ExpectNoError(err, "No response for .../apiservices/v1alpha1.wardle.example.com/status. Error: %v", err) wardle.Reset() err = json.Unmarshal([]byte(statusContent), &wardle) framework.ExpectNoError(err, "Failed to process statusContent: %v | err: %v ", string(statusContent), err) foundPatchedStatusCondition := false for _, cond := range wardle.Status.Conditions { if cond.Type == "StatusPatched" && cond.Reason == "E2E" && cond.Message == "Set by e2e test" { framework.Logf("Found APIService %v with Labels: %v & Conditions: %v", wardle.ObjectMeta.Name, wardle.Labels, cond) foundPatchedStatusCondition = true break } else { framework.Logf("Observed APIService %v with Labels: %v & Conditions: %v", wardle.ObjectMeta.Name, wardle.Labels, cond) } } framework.ExpectEqual(foundPatchedStatusCondition, true, "The patched status condition was not found. %#v", wardle.Status.Conditions) framework.Logf("Found patched status condition for %s", wardle.ObjectMeta.Name) ginkgo.By(fmt.Sprintf("APIService deleteCollection with labelSelector: %q", apiServiceLabelSelector)) err = aggrclient.ApiregistrationV1().APIServices().DeleteCollection(ctx, metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: apiServiceLabelSelector}) framework.ExpectNoError(err, "Unable to delete apiservice %s", apiServiceName) ginkgo.By("Confirm that the generated APIService has been deleted") err = wait.PollImmediate(apiServiceRetryPeriod, apiServiceRetryTimeout, checkApiServiceListQuantity(ctx, aggrclient, apiServiceLabelSelector, 0)) framework.ExpectNoError(err, "failed to count the required APIServices") framework.Logf("APIService %s has been deleted.", apiServiceName) </ins> cleanTest(ctx, client, aggrclient, namespace) }

[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted


Question: epSlice1NewerGen := epSlice1.DeepCopy() epSlice1NewerGen.Generation = 2 <ins> epTerminatingSlice := epSlice1.DeepCopy() now := metav1.Now() epTerminatingSlice.DeletionTimestamp = &now </ins> testCases := []struct { name         string tracker      *EndpointSliceTracker

As discussed in , Endpoint(Slice) controllers can get stuck if an Endpoints or EndpointSlice resource is stuck in a terminating state. I don't think there's much we can do for Endpoints here since the same name is reused, but EndpointSlice controllers can ignore EndpointSlices in a terminating state. See No response All supported versions Any Any Any Any Any
/sig network
/triage accepted
deleting a service with a finalizer doesn't affect the endpointslice, it doesn't change its status to termination or unready Repro: finalizer to the service and delete it, it keeps waiting until the finalizer is removed with the deletion timestamp set. the endpoint slice associated Do you mean that when the endpoint slice controller detects that the Service is being deleted should switch the endpoint slice status to Terminating? cc:
I don't think we need to do anything special if the Service is waiting to be deleted. There are many legitimate reasons for this to happen, including waiting for infrastructure to be removed. My main concern with a finalizer was that one on an EndpointSlice could cause the controller to get stuck on a Service. We don't have the same risk with a finalizer on a Service - I don't think that would cause the controller to get stuck in any way.
i was unable to repro the issue on my machine: I was monitoring the logs of , and the endpointslice controller never complained about , when I deleted the service. Though, I was able to get the controller to log this error under a different scenario. If we don't explicitly remove the finalizer from the endpointslice, and instead re-create the pod and service like: From what I can understand, because the endpointslice with the finalizer is owned by a service with a different UID than the new endpointslice, it is marked as expected for deletion . The endpointslice controllers calls , which returns true for the endpointslice with the finalizer, because of the above reason. I might be wrong anywhere here, so please let me know if that is the case. As for further action, I'm not sure what can be done here? We could check the endpointslice for finalizers and then skip them . Keen to hear your thoughts about this.


Question: return fmt.Errorf("failed to create fsnotify watcher: %v", err) } defer watcher.Close() <del> if err := watcher.Add(f.Name()); err != nil { return fmt.Errorf("failed to watch file %q: %v", f.Name(), err) </del> <ins> if err := watcher.Add(dir); err != nil { return fmt.Errorf("failed to watch directory %q: %w", dir, err) </ins> } // If we just created the watcher, try again to read as we might have missed // the event.

won't output logs after kubelet rotate log filer of the container. kubectl output logs correctly after the log file is rotated. the config to . So kubelet will rotate the log soon. Build a image with this program a deploy with the previous image. the command No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/area kubelet
/triage accepted /priority important-longterm
/assign since you sent a PR already
Ran into this issue!


Question: } nodeV, _ := nodeConstraints[k] if v != nodeV { <del> glog.V(2).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </del> <ins> glog.V(10).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </ins> return false, []algorithm.PredicateFailureReason{ErrVolumeZoneConflict}, nil } }

Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.


Question: // Detach detaches a volume from the host.  This is only needed when NBD is not // enabled and loop devices are used to simulate a block device. func (u *storageosUtil) DetachVolume(b *storageosUnmounter, devicePath string) error { <ins> klog.V(4).Infof("detaching StorageOS volume %q with namespace %q", b.volName, b.volNamespace) </ins> if !isLoopDevice(devicePath) { return nil }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When a PVC is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign


Question: return o }, args:     []string{"foo"}, <del> expected: "must be greater than or equal to 0", </del> <ins> expected: "--tail must be greater than or equal to -1", </ins> }, { name: "container name combined with --all-containers",

<!-- 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: When attempting to get all log lines using only 10 lines of logs are returned What you expected to happen: All log lines should be returned How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This was introduced in in an attempt to fix another issue where selectors would ignore tail values !=-1. I think the problem here is the logic cannot tell if the was set explicitly by the command line or is simply the initial default value. Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: Kubeadm OS (e.g: ): 18.04.2 LTS (Bionic Beaver) Kernel (e.g. ): Linux ubuntu 4.15.0-45-generic -Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
/sig cli
Maybe is not a bug. See the kubectl help. --tail=-1: Lines of recent log file to display. Defaults to -1 with no selector, showing all log lines otherwise 10, if a selector is provided. I think i mean a selector is provided the --tail should not use -1 ?
Thanks for you reply. There are some background in below tickets, --tail=-1 is one of the option. Please check.
The help indicates that the default is 10 if the selector is used. But if someone explicitly asks for -1 it should still work, at least in my opinion.
Encountering similar behaviour to this myself. Is there any chance whatever fixes get applied can also be applied to the branch? Since that also has strange behaviour around logs with label selectors and setting .

See
This ticket has two issues: First, It's said "TailLines must be greater than or equal to 0", however we can specify -1. kubectl logs -l app=test --tail=-3 error: TailLines must be greater than or equal to 0 kubectl logs -l app=test --tail=-1 : Wed Apr 10 06:51:34 UTC 2019 : Wed Apr 10 06:51:35 UTC 2019 : Wed Apr 10 06:51:36 UTC 2019 : Wed Apr 10 06:51:37 UTC 2019 : Wed Apr 10 06:51:38 UTC 2019 : Wed Apr 10 06:51:39 UTC 2019 : Wed Apr 10 06:51:40 UTC 2019 : Wed Apr 10 06:51:41 UTC 2019 : Wed Apr 10 06:51:42 UTC 2019 : Wed Apr 10 06:51:43 UTC 2019 Second, --tail=-1 is the legacy usage which show all lines, here just return 10 lines. kubectl logs -l app=test --tail=-1 The behavior after fix: Test cases ./kubectl logs -l app=test --tail=-3 ./kubectl logs -l app=test --tail=-1 ./kubectl logs -l app=test --tail=2 ./kubectl logs -l app=test --tail=0
Interesting. I think this also causes to fail: ^-- expected record ^-- some later record (there are only 2 pods running, so is not relevant) ^-- adding makes it work
A bit strange that it finds records a few seconds older as well.. but that's not a big concern, and not relevant for this issue. vs. Although that only happens when the workaround is used: :thinking: P.S.


Question: klog.V(4).Infof("Token is deleted and awaiting removal: %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token has been invalidated") } <del> if !bytes.Equal(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) { </del> <ins> if subtle.ConstantTimeCompare(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) == 0 { </ins> klog.V(4).Infof("Token contents no longer matches %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token does not match server's copy") }

This issue was reported in the Impact An attacker may be able to guess a service account token secret, and impersonate the affected account to read, modify, or delete application data to which the account has access in a Kubernetes cluster. Description Service account token secrets () are a type of secret used to authenticate service accounts. The “Service account token Secrets” section of the Kubernetes “Configuration” documentation does not recommend their usage: Nevertheless, their usage appears to be possible, and may be employed by Kubernetes users. The process of creating a service account token is documented in the “Configure Service Accounts for Pods” documentation section. An incoming service account request is authenticated by first verifying the JWT signature of the token, then by comparing the secret token value embedded in the request, against the server’s record of the value. If the values don’t match, the authentication request is rejected. The comparison is performed in a non constant-time way; that is, it will return as soon as it reaches mismatched bytes between the two values. This leaks information about the token, which may assist attackers in successfully guessing the secret value. The issue is present in function of file (). Recommendation Compare the token secret values in constant-time. This can be achieved by using Go’s of the subtle package. Component kube-apiserver Location Function in file Anything else we need to know? See umbrella issue for current status of all issues created from these findings. The vendor gave this issue an ID of NCC-E003660-PCK and it was finding 16 of the report under the kube-apiserver section. The vendor considers this issue Risk as Informational, High Impact, Exploitability at None To view the original finding, begin on page 45 of the Test Environment Kubernetes 1.24.3
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 security
/assign
/sig auth


Question: fi # If there are no more remaining master replicas: delete routes, pd for influxdb and update kubeconfig <del> if [[ "${REMAINING_MASTER_COUNT}" == "0" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 0 ]]; then </ins> # Delete routes. local -a routes # Clean up all routes w/ names like "<cluster-name>-<node-GUID>"

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.): upgrade test leak Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- What happened: While doing manual upgrade testing, found that I couldn't start a new cluster as the existing firewall rules and external master ip address reservation where preventing kube-up from succeeding after running kube-down What you expected to happen: kube-down to clean up all cluster related resources How to reproduce it (as minimally and precisely as possible):
I tried this on a different GCP project and it didn't reproduce. I'm going to see if there's anything strange about my project.
Ack marking this as non-release-blocker
I think I found the problem. (from ) evaluates to false in bash on my mac. Changing it to fixes my issue. I'll send out a PR.


Question: return nil } clone.Revision = newRevision <del> updated, updateErr := rh.client.Apps().ControllerRevisions(clone.Namespace).Update(clone) </del> <ins> updated, updateErr := rh.client.AppsV1beta1().ControllerRevisions(clone.Namespace).Update(clone) </ins> if updateErr == nil { return nil }

The statefulset controller and controller history implementations should be migrated off of the Apps client (deprecated) and onto the AppsV1BetaClient. Currently there is no user facing issue caused by the use of the deprecated resource, but we should maintain good code hygiene.
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 .
/assign kow3ns
/assign kow3ns
/cc
/assign


Question: const ( hostRootFsPath     = "/rootfs" <del> hostProcMountsPath = "/rootfs/proc/mounts" </del> <ins> hostProcMountsPath = "/rootfs/proc/1/mounts" </ins> nsenterPath        = "nsenter" )

In nsentermounter, reads mounts from . Because is sym link to and the containerized kubelet usually bind mount host rootfs in slave mode, thus containerized kubelet's mounts is different from what host sees. This causes kubelet unable to umount/detach volumes. The right way to do is to read hosts's proc, i.e.


Question: return result, nil } <del> // ServiceReplenishmentUpdateFunc will replenish if the old service was quota tracked but the new is not </del> <ins> // ServiceReplenishmentUpdateFunc will replenish if the service was quota tracked has changed service type </ins> func ServiceReplenishmentUpdateFunc(options *ReplenishmentControllerOptions) func(oldObj, newObj interface{}) { return func(oldObj, newObj interface{}) { oldService := oldObj.(*api.Service) newService := newObj.(*api.Service) <del> if core.QuotaServiceType(oldService) || core.QuotaServiceType(newService) { options.ReplenishmentFunc(options.GroupKind, newService.Namespace, newService) </del> <ins> if core.GetQuotaServiceType(oldService) != core.GetQuotaServiceType(newService) { options.ReplenishmentFunc(options.GroupKind, newService.Namespace, nil) </ins> } } }

master-informing: capz-windows-containerd-master capz-e2e.[It] Conformance Tests conformance-tests ! 2023-03-10 04:56:51 +0000 UTC No response /sig testing
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? ### Since when has it been failing? /sig testing 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
/sig windows /triage accepted
no major change between passing test on 3/9 17:55 PST and failing test on 3/9 20:56 PST
containerd logs have error about failing to unpack azure-cloud-manager on both nodes:
kubelet logs confirm this:
looks to be related to bumping capz to 1.8 which uses the cloud-provider oot image: caused by upgrading to 1.8 capz in combination with using OOT
This looks to be affecting our release jobs as well:
looks like the image being built is linux only () and is being pulled by windows. When setting up the snapshot in containerd it is failing (as it is missing files required by windows)
For the passing test the image is multi-arch manifest, so the windows image pulls properly (azure-cloud-node-manager:)
There is a missing env in the see


Question: "podSelector": "Selects the pods to which this NetworkPolicy object applies. The array of ingress rules is applied to any pods selected by this field. Multiple network policies can select the same set of pods. In this case, the ingress rules for each are combined additively. This field is NOT optional and follows standard label selector semantics. An empty podSelector matches all pods in this namespace.", "ingress":     "List of ingress rules to be applied to the selected pods. Traffic is allowed to a pod if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic source is the pod's local node, OR if the traffic matches at least one ingress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this field is empty then this NetworkPolicy does not allow any traffic (and serves solely to ensure that the pods it selects are isolated by default)", "egress":      "List of egress rules to be applied to the selected pods. Outgoing traffic is allowed if there are no NetworkPolicies selecting the pod (and cluster policy otherwise allows the traffic), OR if the traffic matches at least one egress rule across all of the NetworkPolicy objects whose podSelector matches the pod. If this field is empty then this NetworkPolicy limits all outgoing traffic (and serves solely to ensure that the pods it selects are isolated by default). This field is beta-level in 1.8", <del> "policyTypes": "List of rule types that the NetworkPolicy relates to. Valid options are Ingress, Egress, or Ingress,Egress. If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8", </del> <ins> "policyTypes": "List of rule types that the NetworkPolicy relates to. Valid options are "Ingress", "Egress", or "Ingress,Egress". If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8", </ins> } func (NetworkPolicySpec) SwaggerDoc() map[string]string {

Is this a BUG REPORT or FEATURE REQUEST?: bug report /kind bug What happened: I was reading the documentation for as defined What you expected to happen: To have clear documentation How to reproduce it (as minimally and precisely as possible): Read the following, as seen in the 1.12 docs: Anything else we need to know?: Nope Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Is it a case whereby only can be specified as , or only , or both (note the ) ? If that's the case, do you think the following would make it clearer?
It is confusing to have commas used for English grammar and array element delineation in the same sentence. What about simply this?
sounds like a great fix! Putting out a quick pr with this change now :)


Question: *newCustomResourceObject = *oldCustomResourceObject.DeepCopy() // set status <ins> newCustomResourceObject.SetManagedFields(managedFields) </ins> newCustomResource = newCustomResourceObject.UnstructuredContent() if ok { newCustomResource["status"] = status

What happened: I've performed server-side apply on the subresource. e.g. The request body is the following for example: The CRD itself has status commonly defined as: in the resulting openAPIv3 validation the correct object annotations are set for listType & listMapKey (thanks to controler-gen v0.2.5) What you expected to happen: The patch is applied to the status subresource, and the is properly set. However, one of two things happens: if the status subfield conditions don't exist the request passes through and properly sets the field. But the isn't set if the specific status condition type exits the request fails with 409 Conflict. It conflicts with other managers, e.g. since the is empty. if the exist beforehand for the status subresource, they are cleared after server-side apply on the subresource and become empty. Anything else we need to know?: This is similar to Also somewhat related to Environment: Kubernetes version (use ):
/wg apply
/sig api-machinery
thanks for the detailed post, you're absolutely right that this is related to the two issues that you mentioned. I don't see how we would be able to fix this in 1.18 or any version before that, we're planning on fixing it in 1.19. We should probably update the documentation to mention that this doesn't work for sub-resources, and maybe even disable it altogether for sub-resources.
I'd rather have it working...buggily(that is via ) than having it disabled altogether.
We trying to find out what this doesn’t work and see if we can back port the fix. We’ll keep you posted, thanks!
I can't reproduce this bug right now, would you mind sharing the CRD and exact reproduction steps?
Sure. The server-side application I've investigated in This is the CRD definition: my experimentations are in on line I've changed whether I've used force or not. The raw HTTP req/resp should be written to the output due to
Let me know if there's anything more I can do to help.
The strategy overriding the metadata in status updates of CRD and CR objects seems like it would definitely cause this. were you able to follow the steps at


Question: "Minion", "Namespace", "PersistentVolume", <ins> "ComponentStatus", </ins> ) // these kinds should be excluded from the list of resources

The selflink provided in the api response for component statuses (/api/v1/componentstatuses) is broken. For example: /api/v1/namespaces/componentstatuses/controller-manager (as specified in the response of /api/v1/componentstatuses), will return: { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } while: /api/v1/namespaces/default/componentstatuses/controller-manager, will return the data. In addition, and this is asked for better understanding, are the component statuses namespace scoped? as far as I understood etcd, the scheduler and the controller manager were shared across the kubernetes cluster. If they aren't namespace scoped, what is the logic behind specifing a namespace in these api requests (as shown in ): /api/v1/namespaces/{namespace}/componentstatuses /api/v1/namespaces/{namespace}/componentstatuses/{name} If they are in fact namespace scoped, would you be kind and share an explanation/link to a documentation page?
I agree that it doesn't make a lot of sense for this to be namespaced given what's in it at the moment. Given what I'd like it to contain, the namespace might make more sense in the future. The self link is super broken right now, though, probably due to lack of actual namespace. there's probably a bug in the go-restful setup code for this. Can you take a look at some point? Also it might be worth mentioning that this will probably change in the near future, is working on a replacement.
The whole /componentstatus API is just broken. It needs rewriting.


Question: return err } // Setup event recorder if required. <del> makeEventRecorder(kubeCfg, kubeDeps, nodeName) </del> <ins> makeEventRecorder(kubeDeps, nodeName) </ins> // TODO(mtaufen): I moved the validation of these fields here, from UnsecuredKubeletConfig, //                so that I could remove the associated fields from KubeletConfiginternal. I would

/approve no-issue isn't working on , so I'm trying this instead. /cc
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
thanks


Question: func NewValidatingWebhookConfigurationManager(f informers.SharedInformerFactory) generic.Source { informer := f.Admissionregistration().V1().ValidatingWebhookConfigurations() manager := &validatingWebhookConfigurationManager{ <del> configuration: &atomic.Value{}, lister:        informer.Lister(), hasSynced:     informer.Informer().HasSynced, </del> <ins> configuration:              &atomic.Value{}, lister:                     informer.Lister(), hasSynced:                  informer.Informer().HasSynced, initialConfigurationSynced: &atomic.Value{}, </ins> } // Start with an empty list manager.configuration.Store([]webhook.WebhookAccessor{}) <ins> manager.initialConfigurationSynced.Store(false) </ins> // On any change, rebuild the config informer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
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
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: 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: import ( "os" <ins> utilflag "k8s.io/apiserver/pkg/util/flag" </ins> "k8s.io/apiserver/pkg/util/logs" _ "k8s.io/kubernetes/pkg/client/metrics/prometheus" // for client metric registration _ "k8s.io/kubernetes/pkg/version/prometheus"        // for version metric registration

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I pull the latest code, and run with below cmd. But the cluster is not up. And I notice the kube-, 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 ): GitCommit:"" Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cluster-lifecycle
/assign
Can you please try the fix above?
/assign
/unassign
your pr does not fix it yet? If not, I can help.
The fix from works for me! o/
ok, thanks
reopen , make less modifications.
sorry, i miss hyper...


Question: node := newNode("test-node", simpleDaemonSetLabel) node.Status.Conditions = append(node.Status.Conditions, c.nodeCondition...) node.Status.Allocatable = allocatableResources("100M", "1") <ins> node.Spec.Unschedulable = c.nodeUnschedulable </ins> manager, _, _, err := newTestController() if err != nil { t.Fatalf("error creating DaemonSets controller: %v", err)

DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by


Question: attachResponse, err := c.ec2.AttachVolume(request) if err != nil { <ins> attachEnded = true </ins> // TODO: Check if the volume was concurrently attached? return "", fmt.Errorf("Error attaching EBS volume: %v", err) }

Environment: CoreOS 815.0.0, k8s 1.1.0 () It happens to me quite often that a volume marked as "available" on AWS remains in a "detached" state according to the kubelet: Deleting the pod and recreating it eventually succeeds.
I have some fixes in progress that should fix this
/cc
I can reliably reproduce similar issue, I am not sure it's the same: create a AWS EBS, let's say it has ID Create a pod that uses this EBS: Create the pod. It succeeds eventually: Delete the pod Create the pod again. It will be forever IMO, it's caused by not removing the detached volume from internal map of attached volumes . Subsequent will find it there and it won't even try to attach it again. Patch is available in referenced PR.
can you please confirm that your bugs is the same as I can reproduce? Or do you see different bug, only with similar symptoms?
It is
Was this fixed by ?
I think you referenced the wrong issue / PR, didn't you? As far as I know this is not fixed yet.
Yes, I meant to link . mentioned there that it might fix this issue.
Oh right! It made it to v1.2.0-alpha.4
did not fix this issue (but fixed the DeviceMapping cache invalidation)
I think, what is happening is that you run into an error or timeout while waiting for the disk operation. That leaves the devicecache yet again in an inconsistent state. I have a fix here that just discards the cache on any error. Additionally, it is totally possible that there is concurrent operations which lead to an error and bork the cache. The fix: Unfortunately, this is in our tests still not 100% rock solid. Especially in timeout cases. I'm missing the capability to properly test this to engage in a bigger refactoring of this whole issue. A workaround to actually fixing it properly would be to add a TTL to the cache, so that it eventually starts working again.
Just for information for people who might use the GitHub search, as of Kubernetes 1.1.7 the errors logged by the look like: Deleting the pod or restarting doesn't help, the instance keeps failing attaching the EBS with the same errors if the pod get rescheduled on the same host.

thanks for the fix!
Oh... the same host. I bet I messed up that case... I'm going to move into 1.2 so I take another look at this!
What's the status on this?
I just don't think this is fixable with the volume cache we have. I proposed a PR to remove the cache, and replace it with a map of active attachment operations in progress. A little less efficient, but a lot more correct (presuming passes testing).
How to check what K8 version has this fix?
Is there any progress on this issue? I'm running K8s version v1.5.2, and I'm having similar issues. awsElasticBlockStore volumes are virtually unusable due to one of three errors I'm getting: My volume claim is ReadWriteOnce, so this next error confuses me: And finally: [SchedulerPredicates failed due to persistentvolumeclaims "mysql" not found, which is unexpected., SchedulerPredicates failed due to persistentvolumeclaims "mysql" not found, which is unexpected., SchedulerPredicates failed due to persistentvolumeclaims "mysql" not found, which is unexpected.] Unable to mount volumes for pod "staging-connect-mysql-<id(<id)": timeout expired waiting for volumes to attach/mount for pod "default"/"<id". list of unattached/unmounted volumes=[mysql] Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "default"/"<id". list of unattached/unmounted volumes=[mysql]
Also having the same issue as ^ Should we be using PV+VPC instead of claiming the EBS volume directly from the deployment spec?


Question: } errs = append(errs, fmt.Errorf("Error creating EndpointSlice for Service %s/%s: %v", service.Namespace, service.Name, err)) } else { <del> r.endpointSliceTracker.Update(endpointSlice) </del> <ins> r.endpointSliceTracker.Update(createdSlice) </ins> metrics.EndpointSliceChanges.WithLabelValues("create").Inc() } } for _, endpointSlice := range slicesToUpdate { addTriggerTimeAnnotation(endpointSlice, triggerTime) <del> _, err := r.client.DiscoveryV1beta1().EndpointSlices(service.Namespace).Update(context.TODO(), endpointSlice, metav1.UpdateOptions{}) </del> <ins> updatedSlice, err := r.client.DiscoveryV1beta1().EndpointSlices(service.Namespace).Update(context.TODO(), endpointSlice, metav1.UpdateOptions{}) </ins> if err != nil { errs = append(errs, fmt.Errorf("Error updating %s EndpointSlice for Service %s/%s: %v", endpointSlice.Name, service.Namespace, service.Name, err)) } else { <del> r.endpointSliceTracker.Update(endpointSlice) </del> <ins> r.endpointSliceTracker.Update(updatedSlice) </ins> metrics.EndpointSliceChanges.WithLabelValues("update").Inc() } }

<!-- 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: With EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 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:
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved


Question: err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) Expect(err).To(HaveOccurred(), "while waiting for pod to be running") <del> selector := fields.Set{ "involvedObject.kind":      "Pod", "involvedObject.name":      pod.Name, "involvedObject.namespace": f.Namespace.Name, "reason":                   "Failed", }.AsSelector().String() options := metav1.ListOptions{FieldSelector: selector} events, err := f.ClientSet.CoreV1().Events(f.Namespace.Name).List(options) Expect(err).NotTo(HaveOccurred(), "while getting pod events") Expect(len(events.Items)).NotTo(Equal(0), "no events found") Expect(events.Items[0].Message).To(ContainSubstring(errorText), "subpath error not found") </del> }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Looks like the newly tests are failing: https://k8s-
/assign Also random question to why is the same test run 4 times?
GitHub didn't allow me to assign the following users: kevtaylor. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally
Reiterating the mentions to trigger a notification: <detailsIn response to : can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I suggest unless anyone can define why the events do not appear, we disable that part of the test and just check for error. If you are okay with that please reopen the bug and I'll put in a new fix
it looks like node alpha suite is having some other issues right now that are preventing the tests from being run. So it's not clear right now if the fix helped or not.
it failed again. I did a comparison of a locally running one and the alpha suite. In the log file https://k8s- there are these references But in the locally running tests I don't see that step This running And the events running locally
/reopen


Question: // Remove all bind-mounts for subPaths podDir := path.Join(podsDir, string(volumeToUnmount.PodUID)) <del> if err := mounter.CleanSubPaths(podDir, volumeToUnmount.OuterVolumeSpecName); err != nil { </del> <ins> if err := mounter.CleanSubPaths(podDir, volumeToUnmount.InnerVolumeSpecName); err != nil { </ins> return volumeToUnmount.GenerateError("error cleaning subPath mounts", err) }

Fix status: [x] fixed in master in [x] fixed in release-1.10 branch in , will be in 1.10.0 [x] fixed in release-1.9 branch in , will be in 1.9.7 [x] fixed in release-1.8 branch in , will be in 1.8.11 [x] fixed in release-1.7 branch in , will be in 1.7.16 In SubPath fixes, PR adds bind mount for subpaths. It uses as the path name. The volumename in this path is the container's mount volume name which is also called OuterVolumeSpecName in . This becomes an issue for volume reconstruction when kubelet restarts. Volume scans the volume directories and recover the InnerVolumeSpecName (which is used to construct pod volume paths). Volume reconstruction has not enough information to recover the OuterVolumeSpecName and figure out which volume it maps to. In case kubelet needs to clean up mounts (it happens when volume spec cannot be reconstructed), it will fail to clean up the subpaths because of lacking the OuterVolumeSpecName. We think it is better to use InnerVolumeSpecName for volume subPath instead of OuterVolumeSpecName so that volume clean up can work. The issue we might have is that some users might already deploy a cluster with subpath might already . If the users perform an in-place upgrade, since new version will use InnerVolumeSpecName which might have conflicts with some other older version's OuterVolumeSpecName among different volumes. This change requires clear documentation and communication with the users.
cc
This impacts reconstruction of PVCs, where the inner and outer names are different.
/assign
While testing the e2es against a cluster without the fix, I noticed that subsequent pods using volumes failed to start. My theory is that the unmount volume failed because the subpath was still mounted, and that blocked the volume manager from processing other pods. But I thought that volume manager is supposed to run the unmount volume operation in a separate thread per volume, so this shouldn't happen. Need to inspect the code more carefully to confirm the theory. could the volume reconstruction refactor have a unmount volume call in the main volume manager thread?
runs in reconciler's goroutine - so if that function is blocked, it will not be able to process any more volumes.

Was the problem that failed to unmount volume but got hung/stuck ?
I haven't confirmed for sure, but my guess is that unmount volume failed because the subpath was still mounted
moving into the milestone for discussion /milestone v1.10
/priority critical-urgent /status in-progress
/status approved-for-milestone per discussion in sig-release meeting today
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Re-opening to track fixes in release branches
keeping in the v1.10 milestone until merges
since this is now fixed in 1.10, I'm taking it out of the milestone so that the release team doesn't keep checking it.
Can this issue be closed now?


Question: return wc } <ins> type etcdError interface { Code() grpccodes.Code Error() string } type grpcError interface { GRPCStatus() *grpcstatus.Status } func isCancelError(err error) bool { if err == nil { return false } if err == context.Canceled { return true } if etcdErr, ok := err.(etcdError); ok && etcdErr.Code() == grpccodes.Canceled { return true } if grpcErr, ok := err.(grpcError); ok && grpcErr.GRPCStatus().Code() == grpccodes.Canceled { return true } return false } </ins> func (wc *watchChan) run() { watchClosedCh := make(chan struct{}) go wc.startWatching(watchClosedCh)

TestChangeCRD " TestChangeCRD": 37, Recently, not sure the date. No response_ /sig api-machinery
also flaking in weirdly, this doesn't show up at all in
cc I can't tell if this is related to the openapi change or not
Actually, I think this is an issue either with the test or with watch behavior, not sure which. The test starts 10 watches, lets them run, then waits for them to exit cleanly, and instead, they are getting watch errors. I can't tell if the watch errors are expected or not, or if server or watch client behavior changed here or not. Opened to debug further
and stand out as a recent change to watching
cc on whether the watching changes in could explain this integration test getting watch errors it didn't previously get
also stands out
would explain this integration test getting watch errors it didn't previously get?
the filter is enabled only when the server run option has a positive time duration (the default is zero). I searched the k/k repo, only the unit tests in enables this filter: I did a quick scan of the logs, did not see any graceful termination activity either. I will take a deeper look at the logs
and all merged changes were limited to that filter?
This is a Go test, so the entire test output is treated as the failure message. That output is very different from one failure to the other, so in triage we probably have x different "clusters" with one failure in each, instead of one cluster with x failures. I don't know what triage does with such small clusters.
we have changes in only the the filter adds to the request context, I just searched the code base, did not find any other call site for by default, should block (on a nil channel) If the test is receiving an event, it implies that the following case is executing, right?
xref: ??
Thank you all for deflaking.
/triage accepted