Code change:
kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding, kubeadmconstants.SuperAdminKubeConfigFileName) <del> if _, err := superAdminClient.RbacV1().ClusterRoleBindings().Create( </del> <ins> err = wait.PollUntilContextTimeout( </ins> ctx, <del> clusterRoleBinding, metav1.CreateOptions{}, ); err != nil { return nil, errors.Wrapf(err, "unable to create the %s ClusterRoleBinding", kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding) </del> <ins> retryInterval, retryTimeout, true, func(ctx context.Context) (bool, error) { if _, err := superAdminClient.RbacV1().ClusterRoleBindings().Create( ctx, clusterRoleBinding, metav1.CreateOptions{}, ); err != nil { lastError = err if apierrors.IsAlreadyExists(err) { // This should not happen, as the previous "create" call that uses // the admin.conf should have passed. Return the error. return true, err } // Retry on any other type of error. return false, nil } return true, nil }) if err != nil { return nil, errors.Wrapf(lastError, "unable to create the %s ClusterRoleBinding by using %s", kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding, kubeadmconstants.SuperAdminKubeConfigFileName) </ins> } // Once the CRB is in place, start using the admin.conf client.

Related discussion:
text: master-informing: periodic-kubernetes-e2e-kind-kms ! No response /sig cluster-lifecycle
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
/milestone v1.29
/assign but this test job is maintained by sig auth: /sig auth looks like the API server has decided to consistently fail on an unpolled CRB create API call from the kubeadm client. this did not happen on the kind presubmit jobs here: or kubeadm periodic jobs using the kinder tool: or my local tests. so what is different here and why are we getting informer errors? is this highlighting a bug in core k8s? cc best we can do in kubeadm is make that API call polled. FTR, the API call exactly prior to this failing API call is already polled.
Hello. I want to echo that the code freeze is starting (next week), and we want to ensure that each PR has a chance to be merged and issues can be addressed. Is this PR still targeting the 1.29 release?
FTR, the API call exactly prior to this failing API call is already polled. +1 to have the API call polled just as the API call with .
here is the kubeadm PR.
we are tracking a failing test in this ticket and we can proceed with fixing this after code freeze is in effect. i just submitted an associated fix PR here:
As the Alpha 3 release cut is approaching (2nd Nov) /priority critical-urgent
/assign
we have a couple of kubeadm passes here: of the presubmit variant of this job: pull-kubernetes-e2e-kind-kms this seems like a flake and not a failure, given the offending PR merged on the 27th and looking at the history of the periodic:
we are having the similar issue with i saw in the logs I am not sure what I should do, could you help me?