unable to update route error about cert-utils-operator

[raffaelespazzoli]

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.

[tchellomello]

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

[tchellomello]

Thanks, @raffaelespazzoli for your assistance.

I'm closing this issue.