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
While performing first-time configuration, I mistakenly omitted the DNS record for the subdomain domain that I'm generating a cert for. When I corrected that issue, I got a rate-limit error, suggesting that the Cert-manager was repeatedly submitting authorizations for broken configuration.
Here's the log:
2016/09/08 16:53:21 Starting Kubernetes Certificate Controller...
2016/09/08 16:53:21 Kubernetes Certificate Controller started successfully.
2016/09/08 16:53:21 Get http://127.0.0.1:8001/apis/stable.hightower.com/v1/namespaces/default/certificates: dial tcp 127.0.0.1:8001: getsockopt: connection refused
2016/09/08 16:53:26 Watching for certificate events.
2016/09/08 16:53:26 Starting reconciliation loop.
2016/09/08 17:05:38 Creating new Let's Encrypt account: <domain>
2016/09/08 19:21:36 lookup <domain> on <ip>:53: no such host
<above error repeated>
2016/09/08 19:48:15 Error authorizing account: 429 urn:acme:error:rateLimited: Error creating new authz :: Too many currently pending authorizations.
Looking at the code, it appears that the error message text is not from the cert-manager code, and so I'm guessing it's raised in the Authorize method.
Thoughts on whether it's worth trying to catch this error case before spamming the rate limit on authorizations, perhaps by testing explicitly for it before submitting the authorization?
The text was updated successfully, but these errors were encountered:
While performing first-time configuration, I mistakenly omitted the DNS record for the subdomain domain that I'm generating a cert for. When I corrected that issue, I got a rate-limit error, suggesting that the Cert-manager was repeatedly submitting authorizations for broken configuration.
Here's the log:
Looking at the code, it appears that the error message text is not from the cert-manager code, and so I'm guessing it's raised in the Authorize method.
Thoughts on whether it's worth trying to catch this error case before spamming the rate limit on authorizations, perhaps by testing explicitly for it before submitting the authorization?
The text was updated successfully, but these errors were encountered: