Closed tchellomello closed 2 years ago
usually that error is transient, and it happens when two operators update an object at the same time. It's the optimistic locking mechanism inside the go-client. Retrying usually fixes the error, so I was going to ask if eventually the operator was able to put the certs in the secret. It looks like now from the manifest you shared, but can you confirm? anything else suspect in the log. The reason why you see the secret is that you are setting it as the ingress default (so that every route will get it unless a route specific in defined) and you are setting it as a route specific secret. You only need it once, being it a wildcard secret, it should probably be set as the default cert in the ingress.
thanks for your quick response @raffaelespazzoli
yes, the cert-manager
operator created and populate the wildcard-testing-local-tls-cert
secret and then which was later consumed by the route
. If I inspect the route
object, I can see the cert-utils-operator
kubectl get routes wildcard-https -o yaml | kubectl neat
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
cert-utils-operator.redhat-cop.io/certs-from-secret: wildcard-testing-local-tls-cert
cert-utils-operator.redhat-cop.io/inject-CA: "false"
route.openshift.io/termination: edge
labels:
app: hello-world
type: testing-local
name: wildcard-https
namespace: default
spec:
host: wildcard.testing.local
port:
targetPort: 8080-tcp
tls:
certificate: |
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE----
insecureEdgeTerminationPolicy: Redirect
key: |
-----BEGIN RSA PRIVATE KEY-----
xxxxx
-----END RSA PRIVATE KEY-----
termination: edge
to:
kind: Service
name: hello-world
weight: 100
wildcardPolicy: Subdomain
I also can confirm that whenever I renew the certificate via cert-manager
, the operator does it job updating the secret.
For example:
before
$ curl -k -L -v https://b.testing.local 2>&1 >/dev/null | grep 'date:' | head -n2
* start date: Mar 28 18:46:39 2022 GMT
* expire date: Jun 26 18:46:39 2022 GMT
refresh cert
$ kubectl cert-manager renew -n default wildcard
Manually triggered issuance of Certificate default/wildcard
after
$ curl -k -L -v https://b.testing.local 2>&1 >/dev/null | grep 'date:' | head -n2
* start date: Mar 29 14:36:38 2022 GMT
* expire date: Jun 27 14:36:38 2022 GMT
Upon refresh, the cert-utils-operator
logs seem to be fine
[cert-utils-operator-controller-manager-644575f449-ff67v manager] 2022-03-29T14:44:52.272Z DEBUG util.api object is not ConditionsAware, not setting status
[cert-utils-operator-controller-manager-644575f449-ff67v manager] 2022-03-29T14:44:52.272Z DEBUG util.api object is not ConditionsAware, not setting status
[cert-utils-operator-controller-manager-644575f449-ff67v manager] 2022-03-29T14:45:10.923Z DEBUG controller-runtime.manager.events Warning {"object": {"kind":"Secret","namespace":"default","name":"wildcard-testing-local-tls-cert","uid":"2c0cc2b1-f326-48e6-b0f2-9422857cd3cc","apiVersion":"v1","resourceVersion":"1553226"}, "reason": "Certs Soon to Expire", "message": "Certificate expiring in 89 days"}
[cert-utils-operator-controller-manager-644575f449-ff67v manager] 2022-03-29T14:45:10.989Z DEBUG util.api object is not ConditionsAware, not setting status
[cert-utils-operator-controller-manager-644575f449-ff67v manager] 2022-03-29T14:45:10.990Z DEBUG util.api object is not ConditionsAware, not setting status
So @raffaelespazzoli is it safe and expected then to assume the race condition error? Thanks
Thanks, @raffaelespazzoli for your assistance.
I'm closing this issue.
I'm testing the
cert-utils-operator
on Openshift 4.9.21 and I'm hitting the error below:Some of the artifacts that I'm using:
custom domain
certificate
route
Running a
curl
command I can see the certificate without problems, but why is the operator throwing this error?Thanks mmello