Question: proxyMode := getProxyMode(string(config.Mode), iptInterface, iptables.LinuxKernelCompatTester{}) if proxyMode == proxyModeIPTables { glog.V(0).Info("Using iptables Proxier.") <del> var nodeIP net.IP if config.BindAddress != "0.0.0.0" { nodeIP = net.ParseIP(config.BindAddress) } else { </del> <ins> nodeIP := net.ParseIP(config.BindAddress) if nodeIP.Equal(net.IPv4zero) || nodeIP.Equal(net.IPv6zero) { </ins> nodeIP = getNodeIP(client, hostname) } if config.IPTables.MasqueradeBit == nil {

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network


Question: experimental-allowed-unsafe-sysctls experimental-bootstrap-kubeconfig experimental-keystone-url <ins> experimental-keystone-ca-file </ins> experimental-mounter-path experimental-mounter-rootfs-path experimental-nvidia-gpus

Hi, I tried to integrate the keystone auth plugin (which would be perfect for my needs) into the cluster I'm currently setting up. However, I can't get the connection working since our keystone installation is currently only reachable over http As far as I can see in , there is no option to deactivate this check. I think this should be an optional parameter on startup, similar to defaulting to the check being activated.
I don't think we should enable username/password checking over http.
I agree that we are loosing a security layer here, but you can't guarantee you got the password from client over https, so it might be intercepted at this point anyways. More general, I think the proper way to authenticate to Kubernetes with the Keystone plugin using tokens since they will limited lifetime restricted on keystone only which is a big deal regarding keystone likely being bound to a LDAP and thus the password being valid for other services. So I don't want to check username/password directly. I'm just starting out with the Keystone plugin, so I want to point this out in general, if token auth is supported, the better. Couldn't try it in praxis for now since I can't get the auth URL running.
Assigning to to add a priority label.
Setting the priority low until we have a sense of how many users have this restriction (keystone only reachable over http).
I ran into this same issue with trying to deploy kubernetes with devstack in the same vm and wanted to test integration and do some development. I think there are a significant number of developers in this same boat. http is secure enough since it doesn't leave the developers vm and it isn't intended for production. The use case is the same as:
I'd vastly prefer allowing specifying the CA for the keystone server over allowing http auth calls carrying usernames and passwords
I don't disagree. :) But, I also think Kubernetes shouldn't handle the usernames/passwords at all. In http mode, sending a token is much less risky then a username/password since they expire relatively quickly. See this issue for details:
I agree tokens would be preferable, but I wouldn't expect credentials of any kind sent over http to remote servers
Agreed. No one in their right mind should be passing creds or bearer tokens over http over a network.

I'm just interested in being able to easily deploy a k8s in DevStack with a simple plugin, where that k8s is hooked into the deployed keystone so that we can start developing things in OpenStack that depend on k8s. This gives developers a smooth/easy experience to then focus on doing the development stuff and not have to mess with setting up a CA/k8s, which will prevent some of them from contributing to k8s/OpenStack. The idea is simple for developers, secure for operators. Totally separate use cases.
It should be as simple as telling k8s to trust the keystone cert as a CA (assuming the self-signed cert generated by keystone is correctly marked as a CA, which it should be, since it is signing for itself). I've seen too many production installations running with http or untrusted TLS settings to believe that only developers will use this option if it's made available.
I didn't think Devstack could easily deploy with SSL enabled, but it looks like you can: So http support might not be as important as I thought. It could be relegated to a documentation issue for deploying Devstack in this mode when deploying with Kubernetes. We'd still need a way to specify the root CA though for Keystone.
So, I played around with this a little. For my current non devstack based system, I've deployed kubernetes as a cluster running on my laptop deployed as a set of pods via /etc/kubernetes/manifests. Only kubelet is native and all the rest of the services are containers direct from google. Its working well, but since I have 3 api server containers, and get the containers direct from google, I'd have to jump through a bunch of hoops to add the keystone ssl ca cert to each of the containers. I still think an option to specify the ssl cert for keystone would be useful rather then having to merge it into the system's chain of trust.
That's how I'd want to handle this as well


Question: "//pkg/probe/http:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/internalversion:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/fields:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/net:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/registry/generic:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/registry/rest:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/storage:go_default_library", </ins> ], )

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: tried to get listing of all componentstatuses using a labelSelector query selector. I am hitting the apiServer directly. GET /api/v1/componentstatuses What you expected to happen: GET /api/v1/componentstatuses with labelSelector should limit responses to only componentstatuses with the specified label How to reproduce it (as minimally and precisely as possible): run GET /api/v1/componentstatuses with and without a labelSelector against the apiServer. Anything else we need to know?: specifically my label selector is in the form . and i can confirm everything works as expected when i hit GET /api/v1/pods Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.6+IKS", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-05-09T13:26:51Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: IBM OS (e.g: ): Mac Kernel (e.g. ): Darwin Kernel Version 18.5.0 Install tools: Using javascript npm request to talk to api server Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
i assume its because you cant add a label to componentstatus, but they still shouldnt return if i specify a labelSelector
that's indeed a bug i presume. but what use-case makes you label-querying componentstatus?
we have a bot to periodically run a query that finds all known endpoints on the ApiServer. Then for each of the found endpoints, find all resources with our label defined. sort of an inventory tracking system.
in a similar vein, the endpoint doesnt seem to respect
/priority backlog /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /priority backlog /help Instructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I will take a look at this unless no objections
thank you, yours!
a PR for the ComponentStatus API, could you pls kindly take a look? I will look into the metrics API probably over the weekend. Thanks
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


Question: // give the kube api server an "identity" it can use to for request header auth // so that aggregated api servers can understand who the calling user is s.Authentication.RequestHeader.AllowedNames = []string{"ash", "misty", "brock"} <ins> // create private key signer, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader) if err != nil { return result, err } </ins> // make a client certificate for the api server - common name has to match one of our defined names above <ins> serial, err := rand.Int(rand.Reader, new(big.Int).SetInt64(math.MaxInt64-1)) if err != nil { return result, err } serial = new(big.Int).Add(serial, big.NewInt(1)) </ins> tenThousandHoursLater := time.Now().Add(10_000 * time.Hour) <del> clientCrtOfAPIServer, signer, err := pkiutil.NewCertAndKey(proxySigningCert, proxySigningKey, &pkiutil.CertConfig{ Config: cert.Config{ </del> <ins> certTmpl := x509.Certificate{ Subject: pkix.Name{ </ins> CommonName: "misty", <del> Usages: []x509.ExtKeyUsage{ x509.ExtKeyUsageClientAuth, }, </del> }, <del> NotAfter:           &tenThousandHoursLater, PublicKeyAlgorithm: x509.ECDSA, }) </del> <ins> SerialNumber: serial, NotBefore:    proxySigningCert.NotBefore, NotAfter:     tenThousandHoursLater, KeyUsage:     x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{ x509.ExtKeyUsageClientAuth, }, BasicConstraintsValid: true, } certDERBytes, err := x509.CreateCertificate(rand.Reader, &certTmpl, proxySigningCert, signer.Public(), proxySigningKey) </ins> if err != nil { return result, err } <del> if err := pkiutil.WriteCertAndKey(s.SecureServing.ServerCert.CertDirectory, "misty-crt", clientCrtOfAPIServer, signer); err != nil { </del> <ins> clientCrtOfAPIServer, err := x509.ParseCertificate(certDERBytes) if err != nil { </ins> return result, err } <ins> // write the cert to disk certificatePath := filepath.Join(s.SecureServing.ServerCert.CertDirectory, "misty-crt.crt") certBlock := pem.Block{ Type:  "CERTIFICATE", Bytes: clientCrtOfAPIServer.Raw, } certBytes := pem.EncodeToMemory(&certBlock) if err := cert.WriteCert(certificatePath, certBytes); err != nil { return result, err } // write the key to disk privateKeyPath := filepath.Join(s.SecureServing.ServerCert.CertDirectory, "misty-crt.key") encodedPrivateKey, err := keyutil.MarshalPrivateKeyToPEM(signer) if err != nil { return result, err } if err := keyutil.WriteKey(privateKeyPath, encodedPrivateKey); err != nil { return result, err } </ins> s.ProxyClientKeyFile = filepath.Join(s.SecureServing.ServerCert.CertDirectory, "misty-crt.key") s.ProxyClientCertFile = filepath.Join(s.SecureServing.ServerCert.CertDirectory, "misty-crt.crt")

found this by running tests on this PR: it's problematic for a couple of reasons: prevents kubeadm from moving out (eventually) there are no API guarantees in the given code/structs/functions in pkiutils the logic in cmd/kube- must be reworked to generate cert/key pair without using kubeadm. originally in pending fix PR
/sig api-machinery cluster-lifecycle architecture /area code-organization
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api-machinery sig-cluster-lifecycle architecture /area code-organization </details
/assign
cc
Please make sure to add an import restriction to prevent a regression in the future.
/triage accepted


Question: } // createClientBuilders creates clientBuilder and rootClientBuilder from the given configuration <del> func createClientBuilders(logger klog.Logger, c *config.CompletedConfig) (clientBuilder clientbuilder.ControllerClientBuilder, rootClientBuilder clientbuilder.ControllerClientBuilder) { </del> <ins> func createClientBuilders(c *config.CompletedConfig) (clientBuilder clientbuilder.ControllerClientBuilder, rootClientBuilder clientbuilder.ControllerClientBuilder) { </ins> rootClientBuilder = clientbuilder.SimpleControllerClientBuilder{ ClientConfig: c.Kubeconfig, } if c.ComponentConfig.KubeCloudShared.UseServiceAccountCredentials { <del> if len(c.ComponentConfig.SAController.ServiceAccountKeyFile) == 0 { // It's possible another controller process is creating the tokens for us. // If one isn't, we'll timeout and exit when our client builder is unable to create the tokens. logger.Info("Warning: --use-service-account-credentials was specified without providing a --service-account-private-key-file") } </del> clientBuilder = clientbuilder.NewDynamicClientBuilder( restclient.AnonymousClientConfig(c.Kubeconfig),

The kube-controller-manager issues a warning during startup when is specified without providing a . This warning is misleading because the legacy service account token controller, which relies on the , is no longer required for most modern Kubernetes clusters unless explicitly needed for generating long-lived tokens. Additionally, the documentation does not clearly state the purpose of this flag or its impact on legacy token mechanisms. I expected that the warning related to the would either not appear or be updated to reflect its relevance only to the legacy token mechanism. Furthermore, I expected the documentation to clearly explain that this flag is only necessary for enabling the legacy service account token controller and to provide updated guidance on generating long-lived tokens. kube-controller-manager with the --use-service-account-credentials flag but without the --service-account-private-key-file flag. the warning message that is issued during initialization. the current documentation for kube-controller-manager flags and the process for generating long-lived service account tokens. for context <details</details<detailsBare metal </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig auth


Question: const ( fileMode        = "file_mode" dirMode         = "dir_mode" <ins> gid             = "gid" </ins> vers            = "vers" defaultFileMode = "0755" defaultDirMode  = "0755"

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

Anyway, I am working on a PR to support if no gid setting in azure file storage class, while if both sets, only gid from storage class would be used.
while the code is quite different than just add below 3 lines of code, actually below does not work: I will show you the PR tomorrow.


Question: docker manifest push --purge ${MANIFEST_IMAGE}:${IMAGE_TAG} unit-test: <del> docker run --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  </del> <ins> docker run --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes$(DOCKER_VOL_OPTS) -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  </ins> /bin/bash -c "CGO_ENABLED=0 go test -v k8s.io/kubernetes/cluster/images/etcd/migrate" # Integration tests require both a golang build environment and all the etcd binaries from a `k8s.gcr.io/etcd` image (`/usr/local/bin/etcd-<version>`, ...).

Part of What happened: Attempt to run as a non-root user Get What you expected to happen: It runs How to reproduce it (as minimally and precisely as possible): /sig release /sig cluster-lifecycle /area security And as part of kubeadm v1.16 milestone: /milestone v1.16 /priority critical-urgent
/assign randomvariable /lifecycle active
/priority important-soon


Question: set +o errexit } <ins> run_crd_deletion_recreation_tests() { set -o nounset set -o errexit create_and_use_new_namespace kube::log::status "Testing resource creation, deletion, and re-creation" output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-cluster-scoped.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-cluster-scoped-resource.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl delete -f hack/testdata/CRD/example-crd-1-cluster-scoped.yaml) kube::test::if_has_string "${output_message}" 'deleted' # Invalidate local cache because cluster scoped CRD in cache is stale. # Invalidation of cache may take up to 10 minutes and we are manually # invalidate cache and expect that scope changed CRD should be created without problem. kubectl api-resources output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-namespaced.yaml) kube::test::if_has_string "${output_message}" 'created' output_message=$(kubectl apply -f hack/testdata/CRD/example-crd-1-namespaced-resource.yaml) kube::test::if_has_string "${output_message}" 'created' # Cleanup kubectl delete -f hack/testdata/CRD/example-crd-1-namespaced-resource.yaml kubectl delete -f hack/testdata/CRD/example-crd-1-namespaced.yaml set +o nounset set +o errexit } </ins> run_kubectl_explain_tests() { set -o nounset set -o errexit

<!-- 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 --Changing the scope field of a CRD ist not possible since it's immutable. But even after deleting and re-creating the CRD with changed scope it doesn't let me create resources of the CRD's kind. Re-creating CRD with changed scope should just work. Here is a full example that in the end leads to the error when trying to create a resource after re-creating the CRD. Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: vSphere 7.0 OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1160.42.2.el7.x86_64
/sig api-machinery
/assign /triage accepted
This appears to be working as intended. The example custom resource you use: It Cluster scoped because it has no namespace. But once the CRD is namespace scoped, you should not be able to create cluster scoped custom resources of that type. If instead you add a namespace to Example, it should be created, e.g.:
if the above seems to have answered your question - please feel free to close the issue :) Thank you!
kubectl will automatically use the namespace so this is definitely not the issue here. I can reproduce this issue with my above script in a fresh (v1.22.2) cluster. You can add the namespace in the last manifest, it makes no difference. From my understanding this really seems to be a bug.
Yes, that's true. Good catch. Okay, we need to root cause this.
I tried using curl to create the custom resource directly against the API and got the same result: So the problem seems to be in the API server (not in kubectl).
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: "math" "net" "net/http" <del> "os" </del> "path" "path/filepath" "strconv"

What happened: follow on to Need to comment and avoid checking UID on windows. requires some research into what we should be checking so that we can add appropriate TODO. What you expected to happen: Lets also check this at the call site, Anything else we need to know?: Environment: Kubernetes version (use ): master OS (e.g: ): windows
/assign
/assign
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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
/sig windows
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Hi yeah I am already working on this :)
Started branch for this here
thanks
Hey guys is there anything I can do here?
If you want to test perks patch that would be great ?
That sounds great Where do I get started?
Hey ! is there anything I can help with? and how?
I dont think there is anything left to do anything more that you think we need to do to get this merged?
Tested this with containerd as well, I think its good to test
/triage accepted


Question: } }) <del> It("should set fsGroup for one pod", func() { </del> <ins> It("should set fsGroup for one pod [Slow]", func() { </ins> By("Checking fsGroup is set") pod := createPodWithFsGroupTest(config, testVol, 1234, 1234) By("Deleting pod") framework.DeletePodOrFail(config.client, config.ns, pod.Name) }) <del> It("should set same fsGroup for two pods simultaneously", func() { </del> <ins> It("should set same fsGroup for two pods simultaneously [Slow]", func() { </ins> fsGroup := int64(1234) By("Create first pod and check fsGroup is set") pod1 := createPodWithFsGroupTest(config, testVol, fsGroup, fsGroup)

created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests


Question: deps = [ "//pkg/api/pod:go_default_library", "//pkg/apis/core:go_default_library", <ins> "//staging/src/k8s.io/api/core/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/validation/field:go_default_library", ], )

<!-- 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: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:


Question: return printTemplate(&rsForRevision.Spec.Template) } if deployment.Spec.Paused { <del> return "", fmt.Errorf("you cannot rollback a paused deployment; resume it first with 'kubectl rollout resume deployment/%s' and try again", name) </del> <ins> return "", fmt.Errorf("you cannot rollback a paused deployment; resume it first with 'kubectl rollout resume' and try again") </ins> } // Skip if the revision already matches current Deployment

when i rollout undo a pause deployment, it prints a command without namespace. Then i copy and run, it failed with a not found error. it should print a command that can be run correctly. kubectl rollout pause a deployment, then kubectl rollout undo it. copy the command in printed message. No response <details25.0 </details<detailsno </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli


Question: Time metav1.Time // String detailing the error encountered during Attach or Detach operation. <del> // This string maybe logged, so it should not contain sensitive </del> <ins> // This string may be logged, so it should not contain sensitive </ins> // information. // +optional Message string

This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in


Question: // Generate a pod name that is unique among nodes by appending the nodeName. func generatePodName(name string, nodeName types.NodeName) string { <del> return fmt.Sprintf("%s-%s", name, nodeName) </del> <ins> return fmt.Sprintf("%s-%s", name, strings.ToLower(string(nodeName))) </ins> } func applyDefaults(pod *api.Pod, source string, isFile bool, nodeName types.NodeName) error {

<!-- 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 created a static pod for etcd as following with vsphere as cloud provider: But the hostname is using upper name, and when kubelet start the etcd static pod, it will report error as follows: I think that the vsphere should not return upper case hostname, but only lower case hostname. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area cloudprovider
Here is a quick
/sig node


Question: return ssName, instanceID, *(cachedVM.(*compute.VirtualMachineScaleSetVM)), nil } <ins> func (ss *scaleSet) GetProvisioningStateByNodeName(name string) (provisioningState string, err error) { _, _, vm, err := ss.getVmssVM(name) if err != nil { return provisioningState, err } return *vm.ProvisioningState, nil } </ins> // getCachedVirtualMachineByInstanceID gets scaleSetVMInfo from cache. // The node must belong to one of scale sets. func (ss *scaleSet) getVmssVMByInstanceID(resourceGroup, scaleSetName, instanceID string) (vm compute.VirtualMachineScaleSetVM, err error) {

Implement proposal for Azure We should implement interface in Azure cloud provider. returns true if the instance is in stopped state to detach volumes. But if instance is deleted we should not return error. Related features: Related proposal: Related PRs: /kind feature /sig azure /cc
- can you assign me on this one ? I already have a PR in flight.
That's great! /assign just loop in for this RP review, thanks.
GitHub didn't allow me to assign the following users: yastij. Note that only and repo collaborators can be assigned. <detailsIn response to : That's great! /assign just loop in for this RP review, thanks. 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
o, you are not a k8s member yet, anyway, you could send out the PR for this feature, related to this issue, thanks.
Thanks, looking forward to your PR.


Question: } return nil } <ins> func extractDeviceAndPrefix(mntPath string) (string, string, error) { ind := strings.LastIndex(mntPath, "/") if ind < 0 { return "", "", fmt.Errorf("iscsi detach disk: malformatted mnt path: %s", mntPath) } device := mntPath[(ind + 1):] // strip -lun- from device path ind = strings.LastIndex(device, "-lun-") if ind < 0 { return "", "", fmt.Errorf("iscsi detach disk: malformatted mnt path: %s", mntPath) } prefix := device[:ind] return device, prefix, nil } func extractPortalAndIqn(device string) (string, string, error) { ind1 := strings.Index(device, "-") if ind1 < 0 { return "", "", fmt.Errorf("iscsi detach disk: no portal in %s", device) } portal := device[0:ind1] ind2 := strings.Index(device, "iqn.") if ind2 < 0 { return "", "", fmt.Errorf("iscsi detach disk: no iqn in %s", device) } ind := strings.LastIndex(device, "-lun-") iqn := device[ind2:ind] return portal, iqn, nil } </ins>

During iscsi volume cleanup, kubelet reads from and retrieves a list of device paths where iscsi volume mounts on. The device path was expected to be in the form of . But currently the device path in is in the form of , thus iscsi panicked . I suspect this panic started to happen after switched to use from . seems to always resolve device path (see output below), and thus the expected iscsi configuration in the device path no longer exists.


Question: cachedNodeNameToInfo map[string]*schedulercache.NodeInfo } <ins> func (f *FakeExtender) Name() string { return "FakeExtender" } </ins> func (f *FakeExtender) IsIgnorable() bool { return f.ignorable }

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


Question: } func ReadUrl(url string, client *http.Client, header *http.Header) (body []byte, err error) { <ins> retryInterval := time.Second wait.PollImmediate(retryInterval, readURLTimeout, func() (bool, error) { body, err = readUrl(url, client, header) if err != nil { glog.V(4).Infof("Error reading %q: %v", url, err) return false, nil } return true, nil }) return body, err } func readUrl(url string, client *http.Client, header *http.Header) (body []byte, err error) { </ins> req, err := http.NewRequest("GET", url, nil) if err != nil { return nil, err

http://pr-
Something holding the port already?
The previous masterless case just barely passed with a 12.5 second timeout (25 tries at 0.5 second interval) I think we just need to increase the timeout.
I randomly sampled 5 green builds and they all have this test (starting kubelet in masterful/less mode) finished in 3s or less. Judging for the successful masterless mode startup before the failure, kubelet spent the most time trying to register credential providers (a 10s gap in the log). The same roughly applies to the failed "masterful mode", based on where the log message stopped. From , the registering process basically tries to access the metadata url to see if the credential provider is enabled. I think this may just be the slow response from the metadata server.
I am wondering even if this issue might be related to a slow response from the metadata server, why it does not show "Registering credential provider: .dockercfg" always in failed logs?
If there is a possibility that ReadUrl in may take longer than expected, would it be preferred to use a Timeout (0) with the http client to not get stuck longer than expected?
I am unsure why it didn't show that, but even in the passing round we see a 10 second gap, which almost maxed out the timeout. I think adding a timeout is reasonable, but I am not sure what value is reasonable given that the previous request took 10s. do you have any idea?
Even I am not sure exactly what should be a reasonable value. My guess would be that if in normal cases, average response time is x seconds (perhaps a guestimate could be computed based on "normal" successful tests), then x could be a starting point, or otherwise another option is choosing something randomly (like 5s). And I think that if at some point, the server is responding in 10s, and even though the test passes, its not normal and something is going wrong.
uses a 10 second timeout, but the request will be retried. Given that we don't retry this request, a short timeout is worrisome. Maybe we should add both retry and timeout in this case.
SGTM.
I reopen this one since pr was reverted.

Noticed a similar hang in: The logs are a bit different from those observed in
if kubelet couldn't start up properly, the test itself should've timed out and logged "Timed out waiting for kubelet to answer at http://127.0.0.1:/healthz; tried 25 waiting 0.5 between each". I am not sure if this failure is related.
failure is not relevant to this issue. The most recent report of such flake was over a week ago. I think the cause is the slow metadata url response in GCE, and that should've been fixed by the recent rollout. I am going to close this issue. Feel free to reopen if there is another occurrence.


Question: "k8s.io/kubernetes/pkg/scheduler/algorithm" "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" schedulerapi "k8s.io/kubernetes/pkg/scheduler/api" <ins> "k8s.io/kubernetes/pkg/scheduler/metrics" </ins> "k8s.io/kubernetes/pkg/scheduler/schedulercache" "k8s.io/kubernetes/pkg/scheduler/util"

<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --As of now in , we have 3 metrics, for end2endLatency, algorithmLatency and BindingLatency. The problem with algorithmLatency is it is a combination of predicate and priority latencies. So breaking down this metric into predicate and priority latencies would be really helpful for performance analysis. For example, as part of the analysis after these metrics were , we were able to find latencies when we have taints & tolerations alone. In fact, ability to drill down on every predicate and priority would be ideal but want to know other's opinions on this.
/cc
+1 please send a PR.
We also have some demonstrations of how this helps with things like highlighting taint and toleration performance and so on. We should update readme info on how to use these along side the scheduler perf stuff as we've done internally .
You need to be careful about what latency means if we are computing multiple different predicates in parallel (if we decide to split it by predicate). Splitting predicate vs priority is definitely a good idea.
Please label this as part of our 1.7 scheduling forensics milestone .
Let's remove the idea of latency entirely, it is confusing - this is just an attempt at measuring predicate and priority timescales, and there is no response latency that we care about in those small (20ms) timescales , (with the exception of maybe the latency of an etcd hit that might happen in a client if the cache is missing information I guess)
Not really - there were cases of predicates which computation could take over a second.

Yes, and even longer on large clusters with things light affinity.... However here I'm just disputing use of the term latency since latency is usually used to refer to the time between the end of a request and the beggining of a response. What we endeavor to do here is really measure round trip execution time, for predicates, in isolation. If we want to measure some kind of latency then I believe we would need to define some notion of a request/response, which has diminished value outside of something like RPC. If we truly were measuring latency (and it might be interesting to do so with tims tracing work) then we might thus look at the time between writing a new unscheduled pod to the system, and the time it takes to start running the scheduler fit functions or something... Tl;dr there are a lot of varying usages and definitions for latency, but almost all of them, with the exception of measurements of virtual function calls, refer to some unavoidable minimum cost that occurs during distributed communication, and in this case, we are simply measuring "execution time of the predicate filter" which is called from inside the same process. (Alternatively I guess it's ok to call it "fitfunctionpredicate_latency", I guess, since then we are using the fit function as the context for a response measurement).
OK, IIUC you object usage of the word 'latency', right? We use it in this context for quite some time, and as I agree that it doesn't fit formal definition, there's no point in changing it now, as it would confuse people even more.
yeah, i really think they should all be refactored to not be named as such, that is my broader point . but if we want to keep those metrics id suggest we at least update the definition in the fields to clarify that latency is defined WRT rather then to a RPC or some other typical latency calc scenario. aplogies for the bike shed, ill move this to a PR :)
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: return result, len(result) > 0 } <ins> // TODO: Most probably splitting this method to a separate thread will visibily // improve throughput of our watch machinery. So what we should do is to: // - OnEvent handler simply put an element to channel // - processEvent be another goroutine processing events from that channel // Additionally, if we make this channel buffered, cacher will be more resistant // to single watchers being slow - see cacheWatcher::add method. </ins> func (c *Cacher) processEvent(event watchCacheEvent) { triggerValues, supported := c.triggerValues(&event)

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
This is pretty much the same failure, that are happening in "gce-enormous" suite and we currently debugging them with The main reason of those failures is that we are terminating all watchers for a particular resource type from time to time, and some of them are actually causing a snowball effect. After more looking into it, my hypothesis is that our machinery for aggregating watchers in apiserver sometimes is just to slow. In particular, I some log in my local branch and what I'm observing is that in etcd_watcher, we are: accumulating objects in incoming channel but also accumulating objects in outgoing channel, and the accumulation there is usually higher [I will send a PR to put those logs into master - they seem to be pretty useful for debugging such issues.] So my current hypothesis is that dispatching watch events to watchers is what is too slow. We will continue debugging.
The logs that I seem to confirm my hypothesis - outgoing channel is generally more full then the incoming channel in etcd_watcher: vs I'm working on the PR that should at least improve the situation.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Please apply the label to this issue if it does not need to be fixed before we launch 1.4. Otherwise please advise on how to proceed with respect to 1.4.
This was a regression - I fixed it by reverting an offending PR: This seems to be fixed now.
I have 33 pods in my container (1 is substantive, the other 32 just run on log files). I get this all the time now. I'm running 1.5.4.
- to be honest, I don't undertsand what your wrote. what is "container" in "33 pods in my container"? Also, if you believe there is a bug somewhere, please open a new issue instead of adding comment to more than half-year-old one.


Question: if err != nil { glog.Errorf("azure attach failed, err: %v", err) detail := err.Error() <del> if strings.Contains(detail, "Code="AcquireDiskLeaseFailed"") { </del> <ins> if strings.Contains(detail, errLeaseFailed) { </ins> // if lease cannot be acquired, immediately detach the disk and return the original error glog.Infof("failed to acquire disk lease, try detach") az.DetachDiskByName(diskName, diskURI, nodeName)

Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.1011+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-30T07:19:12Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.1011+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-30T07:19:12Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): RHEL 7.3 Install tools: Ansible What happened: PVC keeps pending with a new created storage account What you expected to happen: Storage class can find storage account and then create a dynamic pv for pvc to bind How to reproduce it (as minimally and precisely as possible): a new storage account without create any container a storage class as below a pvc annotating this storage class pvc status is pending Anything else do we need to know: After I create a new container "vhds" in storage account of "qewestus", storage class works and pvc is bound
VHD container is a rerequiste. Will update the doc.
.. I was about to open this exact bug. Shouldn't the provisoner create the vhds container ?
yes, there is a todo for this case (also missing storage account)
Another minor issue is, new volumes take a lot of time (tens of mins) to be ext4 formatted. This causes the pod to timeout and fail upon first use! Any way to make this better
fix is in
Can anyone share how to create the vhds container? For those that don't yet have this fix
Easiest is through the portal, browse to your storage account and create a container called
Thats great thanks for the quick response. The automator in me now wants to see if I can automate the creation of that container through powershell ;)
Does the container have to be of type 'Container' ? IE Full public read access??

Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.345+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-11-10T06:07:31Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.345+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-11-10T06:07:31Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} Environment: Linux Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): RHEL 7.3 Install tools: hack/local-up- What happened: storage class pvc annotated with this storage class a pod consume this pvc read/write function with the mounted path pod/pvc the pv status which is "Failed" What you expected to happen: PV should not have "Failed" status before deleted How to reproduce it (as minimally and precisely as possible): Always Anything else do we need to know:
cc
Per message The disk is still being attached. As a result, PV cannot be deleted.
This condition is handled by the PV framework. See However the volume plugin must return which it looks like the Azure volume plugin is not doing.
please help remove label, kubectl can't do anything with this.


Question: import ( "errors" <del> "strings" </del> "k8s.io/apimachinery/pkg/runtime/schema" utilerrors "k8s.io/apimachinery/pkg/util/errors"

<!-- 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've created a CRD with the name . There is no validation specified on the CRD object. Creating the CRD itself succeeds, but attempting to create CRD resources with of that type fails with a validation error. What you expected to happen: I expect to be able to create CRD resources of type without a validation error. How to reproduce it (as minimally and precisely as possible): A normal working CRD example, : Applying this succeeds as expected: Simply changing the name of the CRD kind to breaks however, : CRD creates, but the actual resource fails validation: If you supply the object does create correctly. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Digitalocean VM cluster OS (e.g. from /etc/os-release): Server (Ubuntu 14.04.5) Client (Ubuntu 16.04.4) Kernel (e.g. ): Server (4.4.0-111-generic) Client (4.13.0-38-generic) Install tools: Others:
/sig api-machinery /area custom-resources
is a special suffix for name. When you create a object using , which will be render as instead of plain . That's why error occurs due to missing item list.
This sounds like a bug in , not a thing that should be "fixed" by restricting names.
I think the magic suffix is somewhat unexpected, but in the case that it doesn't change -- I would expect a warning or error when creating a CRD with that name. As for this specific behavior, I would consider it a bug -- there's no indication that the kubectl validation is against a different than the one explicitly specified in the resource, and confusingly disabling validation causes the operation to succeed normally (creating the explicitly defined resource , regardless of magic suffix).
cc
cc
PTAL . It is a kubectl bug.
Thanks! Fix works for me


Question: // SkipUnlessNodeCountIsAtLeast skips if the number of nodes is less than the minNodeCount. func SkipUnlessNodeCountIsAtLeast(minNodeCount int) { <del> if TestContext.CloudConfig.NumNodes < minNodeCount { skipInternalf(1, "Requires at least %d nodes (not %d)", minNodeCount, TestContext.CloudConfig.NumNodes) </del> <ins> if framework.TestContext.CloudConfig.NumNodes < minNodeCount { skipInternalf(1, "Requires at least %d nodes (not %d)", minNodeCount, framework.TestContext.CloudConfig.NumNodes) </ins> } } // SkipUnlessNodeCountIsAtMost skips if the number of nodes is greater than the maxNodeCount. func SkipUnlessNodeCountIsAtMost(maxNodeCount int) { <del> if TestContext.CloudConfig.NumNodes > maxNodeCount { skipInternalf(1, "Requires at most %d nodes (not %d)", maxNodeCount, TestContext.CloudConfig.NumNodes) </del> <ins> if framework.TestContext.CloudConfig.NumNodes > maxNodeCount { skipInternalf(1, "Requires at most %d nodes (not %d)", maxNodeCount, framework.TestContext.CloudConfig.NumNodes) </ins> } } // SkipIfProviderIs skips if the provider is included in the unsupportedProviders. func SkipIfProviderIs(unsupportedProviders ...string) { if framework.ProviderIs(unsupportedProviders...) { <del> skipInternalf(1, "Not supported for providers %v (found %s)", unsupportedProviders, TestContext.Provider) </del> <ins> skipInternalf(1, "Not supported for providers %v (found %s)", unsupportedProviders, framework.TestContext.Provider) </ins> } } // SkipUnlessProviderIs skips if the provider is not included in the supportedProviders. func SkipUnlessProviderIs(supportedProviders ...string) { if !framework.ProviderIs(supportedProviders...) { <del> skipInternalf(1, "Only supported for providers %v (not %s)", supportedProviders, TestContext.Provider) </del> <ins> skipInternalf(1, "Only supported for providers %v (not %s)", supportedProviders, framework.TestContext.Provider) </ins> } }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. They are skipped because they require SSH access to drop the Flexvolume plugin onto the host, but these test clusters do not have SSH access. We should change all Flexvolume tests to use the DaemonSet installation mechanism instead which does not require SSH access. See and Flexvolume tests I'm aware of are below, but there could be more: Looking for help with this bug! /sig storage /priority important-soon /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! --What happened: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. /priority important-soon /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi, Can I work on this issue? I think i know how to handle it.
are you still working on this? I'm interested in helping out as well.
/assign


Question: ctx, cancel := getContextWithCancel() defer cancel() <ins> if _, ok := c.common.diskAttachDetachMap.Load(strings.ToLower(diskURI)); ok { return fmt.Errorf("failed to delete disk(%s) since it's in attaching or detaching state", diskURI) } </ins> _, err = c.common.cloud.DisksClient.Delete(ctx, resourceGroup, diskName) if err != nil { return err

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: We found that cloud provider tries to attach a disk, it totally costs 121s in the end one minute(disk still in being detaching state), azure cloud provider tries to delete that disk and it succeeded 121s, attach disk operation succeeded and finally azure vm has attached one non-existing disk What you expected to happen: should not delete an azure disk when that disk is being attached How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The difficulty here is when a disk is being attached or detached, the disk state is still "unattached", would be the reason why delete disk at that time would succeed: Azure disk RP would have two options to fix this issue: a new disk state: , disk delete operation when disk is being attached or detached Otherwise on azure provider(client) side, we cannot know whether that disk is being attached or detached since the second delete disk operation is done after 1 min Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure


Question: CSIVolumeHealth: {Default: false, PreRelease: featuregate.Alpha}, <del> CSRDuration: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.26 </del> ContainerCheckpoint: {Default: false, PreRelease: featuregate.Alpha}, ControllerManagerLeaderMigration: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.26

Remove the "CSRDuration" feature gate starting in Kube v1.26. PR proposes that the CertificateSigningRequest's Spec.ExpirationSeconds field be promoted to GA in v1.24. It was originally introduced as beta in v1.22 with a corresponding feature gate called "CSRDuration" to optionally disable it (see PR ). If PR is merged and included in v1.24, then in v1.26 the "CSRDuration" feature gate should be removed. See also where a member of SIG-auth asked me to create this issue.
/sig auth
/triage accepted /milestone v1.26
Is this task a ? I would like to be assign to it.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
I'd like to work on this! /assign
Fixed it here:


Question: <del> 2.46 </del> <ins> 2.47 </ins>

agnhost was updated to v2.46 in: However, is failing: . exporting to image exporting layers exporting layers 2.9s done exporting manifest sha256:db8e9d1930d4799d474ea9228d4957d54053c107e10385d77021ef44f567fc69 done exporting config sha256:037153f61da4211d6ec5f00f694639ce15a0bbebf12fa5c86eea059fc3c0b07c done exporting attestation manifest sha256:744b616c276ff7f6518476765c2457e0b2664225ef798ce7e93874450807310b exporting attestation manifest sha256:744b616c276ff7f6518476765c2457e0b2664225ef798ce7e93874450807310b 0.0s done exporting manifest list sha256:29bf785c1a8338d5f7a8be8cae8a2435b94370eecbaa586a61e08454095940cb done pushing layers pushing layers 5.9s done pushing manifest for pushing manifest for 4.3s done DONE 13.2s /workspace/test/images /workspace/test/images/agnhost /workspace/test/images is a manifest list make: * [Makefile:43: all-build-and-push] Error 1 ERROR ERROR: build step 0 "" failed: step exited with non-zero status: 2
2024/02/13 15:34:04 Failed to run some build jobs: [error running [gcloud builds submit --verbosity info --config --substitutions PULLBASEREF=master,PULLBASESHA=,WHAT=agnhost,GITTAG=v20240213-v1.30.0-alpha.

1-173-gc3b2295c3a --project k8s-staging-e2e-test-images --gcs-log-dir gs://k8s-staging-e2e-test-images-gcb/logs --gcs-source-staging-dir gs://k8s-staging-e2e-test-images-gcb/source gs://k8s-staging-e2e-test-images-gcb/source/-7566-469c-a5a0-]: exit status 1] N/A 2024-02-14 No response No response_ /sig testing
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
PR:


Question: } } if !podResized { <del> return </del> <ins> return pod </ins> } kl.podResizeMutex.Lock() defer kl.podResizeMutex.Unlock() fit, updatedPod, resizeStatus := kl.canResizePod(pod) <ins> if updatedPod == nil { return pod } </ins> if fit { // Update pod resource allocation checkpoint if err := kl.statusManager.SetPodAllocation(updatedPod); err != nil { //TODO(vinaykul,InPlacePodVerticalScaling): Can we recover from this in some way? Investigate <del> klog.ErrorS(err, "SetPodAllocation failed", "pod", klog.KObj(pod)) </del> <ins> klog.ErrorS(err, "SetPodAllocation failed", "pod", klog.KObj(updatedPod)) return pod </ins> } <del> *pod = *updatedPod </del> } if resizeStatus != "" { // Save resize decision to checkpoint <del> if err := kl.statusManager.SetPodResizeStatus(pod.UID, resizeStatus); err != nil { </del> <ins> if err := kl.statusManager.SetPodResizeStatus(updatedPod.UID, resizeStatus); err != nil { </ins> //TODO(vinaykul,InPlacePodVerticalScaling): Can we recover from this in some way? Investigate <del> klog.ErrorS(err, "SetPodResizeStatus failed", "pod", klog.KObj(pod)) </del> <ins> klog.ErrorS(err, "SetPodResizeStatus failed", "pod", klog.KObj(updatedPod)) return pod </ins> } <del> pod.Status.Resize = resizeStatus </del> <ins> updatedPod.Status.Resize = resizeStatus </ins> } <del> kl.podManager.UpdatePod(pod) kl.statusManager.SetPodStatus(pod, pod.Status) return </del> <ins> kl.podManager.UpdatePod(updatedPod) kl.statusManager.SetPodStatus(updatedPod, updatedPod.Status) return updatedPod </ins> } // LatestLoopEntryTime returns the last time in the sync loop monitor.

mutates the pod object in place (vs creating a copy first). That's illegal and can cause data races or potentially panics (the panic is unlikely here but I can't rule it out). This line should be: This should be fixed because we might serialize the object in the middle of this from somewhere else and if the object changes midway the protobuf object we create may not be valid, leading to panics in kubelets with this gate turned on. /sig node /priority critical-urgent /kind bug /assign No mutation of pod objects from within methods (in fact no mutation of should occur in most loops). N/A No response <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
ACK. I'll fix it shortly.
is similar. is my try for both data races that we found.
One small , thanks.
Please review
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager


Question: if action.GetSubresource() == "" { err = tracker.Create(gvr, action.GetObject(), ns) } else { <del> // TODO: Currently we're handling subresource creation as an update // on the enclosing resource. This works for some subresources but // might not be generic enough. err = tracker.Update(gvr, action.GetObject(), ns) </del> <ins> oldObj, getOldObjErr := tracker.Get(gvr, ns, objMeta.GetName()) if getOldObjErr != nil { return true, nil, getOldObjErr } // Check whether the existing historical object type is the same as the current operation object type that needs to be updated, and if it is the same, perform the update operation. if reflect.TypeOf(oldObj) == reflect.TypeOf(action.GetObject()) { // TODO: Currently we're handling subresource creation as an update // on the enclosing resource. This works for some subresources but // might not be generic enough. err = tracker.Update(gvr, action.GetObject(), ns) } else { // If the historical object type is different from the current object type, need to make sure we return the object submitted,don't persist the submitted object in the tracker. return true, action.GetObject(), nil } </ins> } if err != nil { return true, nil, err

After I evicted an pod, I performed the operation of the full list instance, but found something that did not meet expectations After pods are evicted, non-evicted ones can be listed normally No response <details</detailsv1.20.0 <details</details<details</details<details</details<details</details<details</details
/sig node
/sig api-machinery /remove-sig node
/remove-sig api-machinery
/assign since you are tagged on the PR. Thanks! /triage accepted
/sig testing
If you have time, please help to look at this pr, thanks
this is a general issue with subresources that accept create requests of different object types than the parent resource see also:


Question: { ObjectMeta: metav1.ObjectMeta{ Name:              "192.168.2.2", <del> CreationTimestamp: metav1.Time{Time: time.Now().AddDate(-10, 0, 0)}, </del> <ins> CreationTimestamp: metav1.Time{}, </ins> }, Spec: networking.IPAddressSpec{ ParentRef: &networking.ParentReference{

and also v1.27-1.29 TestPrintIPAddressList After 03-01 the leap day caused the failure /sig cli network
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: } if addressNodeHostName == nil { hostnameAddress := api.NodeAddress{Type: api.NodeHostName, Address: kl.GetHostname()} <del> node.Status.Addresses = append(nodeAddresses, hostnameAddress) </del> <ins> nodeAddresses = append(nodeAddresses, hostnameAddress) </ins> } else { glog.V(2).Infof("Using Node Hostname from cloudprovider: %q", addressNodeHostName.Address) } <ins> node.Status.Addresses = nodeAddresses </ins> } else { var ipAddr net.IP var err error

codablock on slack reported an issue regarding (paraphrasing) "When used in combination with the Azure cloud provider, I get errors about Node.Status.Addresses being duplicated" Looking at the code, the Azure cloudprovider returns a HostName address, but then a HostName address is also by the kubelet code itself.
cc
I have two PRs with different alternatives: adds a hostname unless the cloudprovider already set one. relies on the cloudprovider to set one, and does not add one. I think has the problem that the cloudprovider has no way to say that Hostnames are not in use. relies on the cloudprovider adding the hostname if it wants it, which is trivial for it to do (the Azure provider already does it). any thoughts on the options?
I'd get the cloudprovider to set one if it wants () and avoid duplicating. I don't think the info from --hostname-override should be lost if the cloudprovider didn't have a hostname opinion


Question: r := cache.NewReflector(nodeLW, &v1.Node{}, nodeIndexer, 0) go r.Run(wait.NeverStop) } <del> nodeInfo := &predicates.CachedNodeInfo{NodeLister: corelisters.NewNodeLister(nodeIndexer)} </del> <ins> nodeInfo := &CachedNodeInfo{NodeLister: corelisters.NewNodeLister(nodeIndexer)} </ins> // TODO: get the real node object of ourself, // and use the real node name and UID.

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I recently saw an issue in which the scheduler hit this log line many times: After some digging, it turns out that PodAffinityChecker has a and . The points at the scheduler's cache instance, while the points at a light wrapper around a . In the scheduler, we use the cache to provide a globally consistent view of the cluster, even if that view is slightly out of date. Data read from the core may not have been processed by the scheduler cache yet. Letting data "skip ahead" like this can cause stale info to get persisted in the scheduler cache, and other subtle bugs. While the original problem is not likely caused by this issue, I think it needs to be cleaned up to avoid potential bugs down the line. What you expected to happen: Predicates should only read state from the scheduler's cache in order to maintain consistency. How to reproduce it (as minimally and precisely as possible): This was observed in a cluster with high rate of pod creation and node creation/deletion. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.5 Cloud provider or hardware configuration: GKE with preemptible nodes OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig scheduling
We do have this kind of issues, and here is another one:
I'm not sure the urgency of this fix, but if its not super urgent, I would love to pick it up, if there's an eng more experienced with the scheduler who could give me some guidance :)
Hi I dug into the source code, and find out is used by the scheduler and kubelet. Maybe we could change the internal struct of , but I do not know why it appears in kubelet which seems irrelevant to the scheduler.
is just a wrapper of corelisters.NodeLister. kubelet can get node info by it.
I think the point is that the kubernetes scheduler was designed to support single instance at the beginning. Even with the addition of multiple scheduler support, the cache between each scheduler is isolated. So at this stage, we can accept this without a shared state solution.

After all, the node information is not actively modified by the kubernetes scheduler.
So is it necessary to ensure the consistency by using node lister instead of cache in the scheduler, or we do not need to fix this issue which seems like to caused by inconsistent cache.
We've recently hit this issue with the scheduler. It appears that our scheduler somehow gets out of sync with the nodes, and start scheduling pods on tainted nodes. The node's kubelet then (rightfully) refuse to admit the pod. Looking at the scheduler logs, they are flooded with the following : Similar scenario, this is a high churn cluster with thousands of pods scheduled per minute - and nodes being autoscaled. Can we try to get a fix ?
I'm glad to pick this up if we decide to fix this issue.
It would be awesome if you could fix this issue for us, we are currently seeing 100's of pods incorrectly being scheduled onto nodes with taints.
The code cited for logging "Node not found, %v" is now in :
/assign
Thanks for the interest on fixing this bug. Sorry I haven't had time to engage on this issue. Feel free to send PRs my way. I'm not 100% certain that this will fix the problem of pods getting scheduled to tainted nodes. How is the taint being applied to the node? Even if the scheduler is internally consistent, there could be a time between node creation and the taint being applied where we send pods to that node.


Question: By("Restart the nfs server") restartNfsServer(nfsServerPod) <del> By("Verify host running the deleted pod is now cleaned up") </del> <ins> By("Verify that the deleted client pod is now cleaned up") </ins> checkPodCleanup(c, pod, true) }) }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: See One /sig storage
/assign
[Slow] test suite was run. Glusterfs io stream test failed due to ns not being deleted, which was due to 1 pod remaining. The glusterfs-server pod was deleted. It appears that the glusterfs-client pod was not deleted even though returned no error. In cases where this test succeeds (which is most of the time) returns which is seen in the log as INFO: Ignore "not found" error above. Pod "gluster-io-client" successfully deleted. Sometimes when the plugin io streaming tests pass you'll see logged for the client pod. However, sometimes a client pod is deleted but the above log entry is not triggered. Eg in you'll see the nfs-client pod is deleted (the ns was able to be deleted) yet the above log msg stating to ignore the "not found" error was not generated. (scroll down to the line "I0724 20:27:20.364] Jul 24 20:27:00.559: INFO: Waiting for pod nfs-io-client in namespace 'e2e-tests-volume-io-pmdks' status to be 'terminated due to deadline exceeded'(found phase: "Running", readiness: true) (29.883170178s elapsed) I0724 20:27:20.365] [AfterEach] [sig-storage] NFS"). My guess is that in this case the plugin's client pod did not terminate in 30s -- WHY NOT THE FULL 5m? -- but did terminate in time for the ns to be deleted. And sometimes the client pod cannot be deleted in 30s (again WHY NOT THE FULL 5m?) and is still present when the ns is deleted. Note: if we cannot detect that the client pod was not actually deleted and then we delete the server pod, there is no chance that the ns can be deleted. Once the server pod is gone the client pod will not delete.
It looks like the client pod failed to terminate:
30s may not always be enough time for the gluster client pod to terminate?

also, why is it so common to see ~29 seconds for the client pods (nfs, gluster) to supposedly terminate. The wait should be for up to 5m yet I never see = 30s wait times... yet, we know that sometimes the gluster client pod is not terminated. Seems like maybe a bug in this area?
can you take a look? My findings so far are this test fails about 20% of the time. The gluster client pod's Status is set to Failed and therefore the pod won't be deleted. There is e2e code that waits for the pod to be deleted but escapes if the pod has "Failed" and if the passed-in reason matches the pod's Status.Reason. In the gluster pod test failures the pod's Status.Reason == "". This causes the test to incorrectly assume that the pod was deleted when it wasn't. This problem manifests itself when the namespace is deleted and that step fails. It seems like the Failed pod's Status.Reason should not be blank. cc
It looks like gluster unmount failed:
But in the log I looked at today (https://k8s-) I see the pod's Status=Running. Then the pod is deleted and the status remains Running for ~30s then changes to Failed. Even though the pod is Failed its Reason remains "". So 1) I wonder why the pod is marked as Running if its mount failed, and 2) once the pod is Failed why is Reason still blank?
It was the unmount that failed, not the mount.
ah, ok thanks, I missed that. Still need to know why Pod.Status.Reason is blank...
Below are some records from a related to the glusterfs-client pod, gluster-io-cliente2e-tests-volume-io-6h140(-778e-11e7-afad-)_ and the "e2e-tests-volume-io-6h140" ns:
I think the issue is that the test is deleting the gluster endpoints before deleting the pod.
Nm, the test does seem to be cleaning up in the correct order: client pod, then server pod and endpoints. So the issue seems to be that during Pod termination, it goes to Failed state.

Before, I thought it was because the unmount failed, but based on the timestamps of the logs, it seems like it fails before we start unmounting.
Just spoke to and he said that it's normal for a Pod to go to Failed state during the termination sequence. In between Failed state and Pod object deletion is when we unmount the volumes. So I think the issue here is that the WaitForPodTerminated function needs to wait only for the Pod object to be deleted, and not return early if Pod state is Failed.
do you have time to look at this? The test is still flaking
yes I can take a look. Do you know if there has been a pr started to address this issue? BTW, I will be gone most of tomorrow but will start tomorrow night.


Question: }, }, }) <ins> if err := e2epod.WaitForPodCondition(ctx, f.ClientSet, f.Namespace.Name, podName, "Ready", 120*time.Second, testutils.PodRunningReady); err != nil { framework.ExpectNoError(err, fmt.Sprintf("Pod %v could not enter running/ready", podName)) } </ins> var ( wsPids []int err    error

Test: [sig-node] Restart [Serial] [Slow] [Disruptive] Kubelet should correctly account for terminated pods after restart I've also seen on /kind flake /sig node Looks like occasionally we have a second 50m CPU pod hanging around on the node, blocking enough pods getting scheduled for the test: I'm a bit puzzled because no pods are listed as currently running when the node dumps debug info. Could be a bug?
another case [sig-node] Container Manager Misc [Serial] Validate OOM score adjustments [NodeFeature:OOMScoreAdj] affected the Restart test case, see the kubelet log, the kubelet-container-manager guaranteede9d81584 pod was received almost simultaneously with the restart-test pod
Since at 0316 21:25:08, the container of pod guaranteede9d81584 has just been creating, but the test case [sig-node] Container Manager Misc [Serial] has already finished at 0316 21:25:06, so the test case check condition may be not strict
/triage accepted /assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

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


Question: func (p *PriorityQueue) AssignedPodUpdated(logger klog.Logger, oldPod, newPod *v1.Pod) { p.lock.Lock() if isPodResourcesResizedDown(newPod) { <ins> // In this case, we don't want to pre-filter Pods by getUnschedulablePodsWithCrossTopologyTerm // because Pod related events may make Pods that were rejected by NodeResourceFit schedulable. </ins> p.moveAllToActiveOrBackoffQueue(logger, AssignedPodUpdate, oldPod, newPod, nil) } else { <del> p.movePodsToActiveOrBackoffQueue(logger, p.getUnschedulablePodsWithMatchingAffinityTerm(logger, newPod), AssignedPodUpdate, oldPod, newPod) </del> <ins> // Pre-filter Pods to move by getUnschedulablePodsWithCrossTopologyTerm // because Pod related events only make Pods rejected by cross topology term schedulable. p.movePodsToActiveOrBackoffQueue(logger, p.getUnschedulablePodsWithCrossTopologyTerm(logger, newPod), AssignedPodUpdate, oldPod, newPod) </ins> } p.lock.Unlock() }

/sig scheduling /kind cleanup Ref: A test helper function creates a goroutine to pop a Pod from the scheduling queue. This goroutine never stops until the scheduling queue is ed or is somehow stopped for waiting for a new Pod. Ideally, when reaching timeout, we should somehow stop from waiting for Pod to be enqueued to activeQ.
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
We can replace this function with and it should be enough? I think we no longer need to maintain this function.
Not enough, the core of this problem is that we cannot cancel once we start . Even if we change function to whatever, we will hit this problem. So, we need:
Or, alternatively and much more easily, maybe we can just replace all with and remove . kills the entire test if reaching timeout and we could care less about leaked goroutine then.
I don't think we can do this. From the test case: The expected behavior of this case is that we receive a timeout to make sure no pods are to . So, reaching timeout is acutally a success. So, I think: option 1: using sth like this in : option2: do sth in the test code This part is where it confused me. The current code is fine as we closed schdulerQueue after called , and after I think there is no test case using this this function anymore(seeems that you refactored the test), so are we trying to solve a potential problem?
Oh, then we can just remove NextPod in the PR.
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/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

/sig scheduling /kind bug AssignedPodAdded(): AssignedPodUpdated(): When assigned Pods are created/updated, cluster events (Pod/Add or Pod/Update) should be delivered for all plugins that subscribe those events. But, actually pre-filters Pods to receive those events based on Pods' affinity and . - meaning only PodAffinity/NodeResourceFit receive them actually. The problem here is similar to - in in-tree plugins, PodAffinity, PodTopologySpread and NodeResourceFit subscribe Pod add and/or update events. And, Pods rejected by PodTopologySpread will never be requeued to activeQ by Pod-related events. The same happens for custom plugins registering pod add and/or update events. All Pods will get chances to get back to activeQ by Pod-related events. Run ↓ in No response <detailsmaster </details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: fs.StringVar(&f.CertDirectory, "cert-dir", f.CertDirectory, "The directory where the TLS certs are located. "+ "If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.") <del> fs.StringVar(&f.CloudProvider, "cloud-provider", f.CloudProvider, "The provider for cloud services. By default, kubelet will attempt to auto-detect the cloud provider (deprecated). Specify empty string for running with no cloud provider, this will be the default in upcoming releases.") </del> <ins> fs.StringVar(&f.CloudProvider, "cloud-provider", f.CloudProvider, "The provider for cloud services. Specify empty string for running with no cloud provider.") </ins> fs.StringVar(&f.CloudConfigFile, "cloud-config", f.CloudConfigFile, "The path to the cloud provider configuration file.  Empty string for no configuration file.") fs.StringVar(&f.RootDirectory, "root-dir", f.RootDirectory, "Directory path for managing kubelet files (volume mounts,etc).")

/kind feature What happened: Continuing the discussion from , we should deprecate (or remove since its alpha) the option to set . See comment and for more details. related issues: related kubernetes-dev thread: !topic/kubernetes-dev/UAxwa2inbTA EDIT: Deprecation plan: [x] v1.8 - deprecate auto-detect cloud provider feature in kubelet [ ] v1.9 - set no cloud provider as the default in kubelet but still allow opt in for auto-detect [ ] v1.10 - completely remove the option to use
/sig cluster-lifecycle
/area cloudprovider
cc
/assign wlan0
cc - Wanted to ask you if you had any thoughts for/against this issue?
/assign andrewsykim As discussed in our meeting I'll be following up with sig-node to see if we can deprecate this as it's going against what we want for external cloud providers
FYI
Would have been nice to keep this issue open to track progress in the next releases
Indeed, should be kept open. Next task is now targeting v1.9
Thanks I edited the issue description to include the deprecation plan going forward. Open to changes on the deprecation plan if we think it's too aggressive.
Great, I think this is a good timeline. We need to make sure we communicate it very well though can you add this to the draft release notes in kubernetes/features please?
Looks like you beat me to it , gave it a review.
hehe, yes, it at the same time as everything else ;)
Can you create a PR for this soon to get this early into v1.9 please?
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners; move out of the milestone after 1 attempt. : Adding tests, refactoring, fixing old bugs. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
i took the liberty to move this along (filed ). Hope that's ok.
Thanks appreciate it. I think there were some discussions in the mailing list thread about v1.9 being too soon.

I think it largely depends on how many users actually take advantage of the auto-detect feature. It's not many from what I've seen but we should follow up and be sure.
Any recent discussion about that? I haven't seen any activity recently but I might just be subject to email overflow. I hope we can get this into v1.9 cc
I didn't follow any discussion related to this topic, but thought this is right move to decouple cloudprovider components from the core system. If I remembered correctly, only cloudproviders for GCE, AWS and Azura depend on the feature, which can be easily override. Any concerns for v1.9?
yep, GCE/AWS/Azure -
Please look at and give your LGTM
Done. Just better document in 1.9 release notes. LGTM
Thank you!
Reopening for the removal of the option in v1.10
please move this to 1.10 milestone


Question: "strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeletstatsv1alpha1 "k8s.io/kubelet/pkg/apis/stats/v1alpha1"

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: While trying to run the node conformance tests with CRIO, the test I noticed failures like on the logs of the test containers. This happens because CRIO doesn't ship with capability enabled by default. Since only this test in requires it, we should add this capability only in this test and not runtime wide. Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: CRIO doesn't ship with by default. Anything else we need to know:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node


Question: "strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeletstatsv1alpha1 "k8s.io/kubelet/pkg/apis/stats/v1alpha1"

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: https://k8s- Reason for failure: Based on the execution conditions sometimes the value of could be 0 instead of expected Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
/sig node
This particular test also fails on CRIO with Fedora CoreOS platform because the return value of is slightly different on that platform.
thank you for opening this issue. Just to have more visibility in the future, and avoid duplicated work, could you please share issues like this one in #sig-node or with the mailist list for CI improvements ? I also see you opened so will assign you this issue /assign /triage accepted /priority important-longterm /cc
thank you for opening and working on this issue. You can check the for issues logged against tests that are producing non-deterministic results. And also it is worth noting that that logged has a for this problem along with the following specific failures
sorry I wasn't aware of CI Signal project board. Thanks for the link.
sorry my bad, I didn't realize there was already an issue for this.
More failures around not having NetworkStats and MemoryStats,
From the kubelet logs of one of the failed jobs. Open the failed job's and look for
helped me to get rid of errors related fsinfo not available. I do some more testing. It's just a temporary patch which looks for because that's what I am using. If it really works, I could make it more generic.


Question: fi fi # Command <del> kubectl label -f "${file}" labeled=true "${kube_flags[@]}" </del> <ins> # We need to set --overwrite, because otherwise, if the first attempt to run "kubectl label" # fails on some, but not all, of the resources, retries will fail because it tries to modify # existing labels. kubectl-with-retry label -f $file labeled=true --overwrite "${kube_flags[@]}" </ins> # Post-condition: mock service and mock rc (and mock2) are labeled if [ "$has_svc" = true ]; then kube::test::get_object_assert 'services mock' "{{${labels_field}.labeled}}" 'true'

shippable flake: It seems that this test needs to retry on update failures. cc who fixed some other similar test flakes recently and might want to take a swing at this one.
cc
We discussed about it in Assigning to
Thanks . Removing team/control-plane, as team/CSI seem to have this in hand.
Aha, my PR was also hit by this flake just now. I'll try to fix this tmr.
has the same problem.


Question: 1.17 will work on the current Aggregator/API-Server. release: v1.17, v1.21 file: test/e2e/apimachinery/aggregator.go <ins> - testname: Aggregator, manage lifecycle of an APIService codename: '[sig-api-machinery] Aggregator should manage the lifecycle of an APIService [Conformance]' description: An APIService is created which MUST succeed. The APIService status when replaced MUST succeed. Given the updating of the APIService status, the fields MUST equal the new values. The APIService status when patched MUST succeed. Given the patching of the APIService status, the fields MUST equal the new values. The APIService when replaced MUST succeed. Given the updating of the APIService, the fields MUST equal the new values. It MUST succeed at deleting a collection of APIServices via a label selector. release: v1.25 file: test/e2e/apimachinery/aggregator.go </ins> - testname: Custom Resource Definition Conversion Webhook, convert mixed version list codename: '[sig-api-machinery] CustomResourceConversionWebhook [Privileged:ClusterAdmin] should be able to convert a non homogeneous list of CRs [Conformance]'

[X] Test approval issue: [X] Test PR: 7 July 2022 [x] Two weeks soak end date: 21 Jul 2022 [x] Test promotion According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. replaceApiregistrationV1APIServiceStatuspatchApiregistrationV1APIServiceStatusreplaceApiregistrationV1APIServicedeleteApiregistrationV1CollectionAPIService Using a number of existing e2e test practices a new has been created for 4 APIService endpoints. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: func init() { jsonSerializer := json.NewSerializer(json.DefaultMetaFactory, schedulerapi.Scheme, schedulerapi.Scheme, true) <ins> serializer := yaml.NewDecodingSerializer(jsonSerializer) </ins> Codec = versioning.NewDefaultingCodecForScheme( schedulerapi.Scheme, <del> jsonSerializer, jsonSerializer, </del> <ins> serializer, serializer, </ins> schema.GroupVersion{Version: Version}, runtime.InternalGroupVersioner, )

Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". In latest scheduler componentconfig API (v1alpha1), it can be a file or a configmap: However, if you defines a scheduler config file and specify a YAML policy file: It doesn't work. It's because only JSON is supported: It'd nice to enhance it with an UniversalSerilizer so as to support both JSON and YAML. /sig scheduling /help /priority important-longterm
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". /help /priority important-longterm </details
/assign


Question: name: "Change image for all containers with set-image", opts: &DebugOptions{ CopyTo:    "myapp-copy", <del> Container: "app", </del> SetImages: map[string]string{"*": "busybox"}, }, havePod: &corev1.Pod{

<!-- 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: Using without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that