You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yesterday we had some failures in talking to the k8s API servers. The failures caused cert-manager to timeout when creating a certificate request. Later on, cert-manager created another certificate request with a higher revision.
Once the API servers recovered, cert-manager was able to process the requests but the certificate ended up with the older of the 2 revisions.
For example:
Current revision: R
First Request Revision: R + 1
Second Request Revision: R + 2
Somehow the certificate's revision pointed to R + 1 instead of R + 2, therefore when cert-manager tried to renew the certificate it failed to create a certificate request with revision R + 2 because one already existed. In this case, cert-manager tries to delete failed requests but not successful ones. Therefore, we were deadlocked on renewing certificates in this state.
We manually deleted all certificate requests in the ready state for the blocked certificates to make progress.
Expected behaviour:
Expect cert-manager to be able to handle duplicate successful requests for the same revision without manual intervention.
Steps to reproduce the bug:
This one is tricky since we don't fully understand the problem. However, it seems similar to #4956.
Anything else we need to know?:
Environment details::
Kubernetes version: 1.26.12
Cloud-provider/provisioner: self-hosted
cert-manager version: 1.12.7
Install method: static manifests
/kind bug
The text was updated successfully, but these errors were encountered:
Describe the bug:
Yesterday we had some failures in talking to the k8s API servers. The failures caused cert-manager to timeout when creating a certificate request. Later on, cert-manager created another certificate request with a higher revision.
Once the API servers recovered, cert-manager was able to process the requests but the certificate ended up with the older of the 2 revisions.
For example:
Current revision: R
First Request Revision: R + 1
Second Request Revision: R + 2
Somehow the certificate's revision pointed to R + 1 instead of R + 2, therefore when cert-manager tried to renew the certificate it failed to create a certificate request with revision R + 2 because one already existed. In this case, cert-manager tries to delete failed requests but not successful ones. Therefore, we were deadlocked on renewing certificates in this state.
We manually deleted all certificate requests in the ready state for the blocked certificates to make progress.
Expected behaviour:
Expect cert-manager to be able to handle duplicate successful requests for the same revision without manual intervention.
Steps to reproduce the bug:
This one is tricky since we don't fully understand the problem. However, it seems similar to #4956.
Anything else we need to know?:
Environment details::
/kind bug
The text was updated successfully, but these errors were encountered: