Test OpenShift serving certificates and TLS registry with REST client

[michalvavrik]

Summary

This is quite similar to what I have done in QE Test Framework quarkus-qe/quarkus-test-framework#1270 because I think it tests all we need from TLS Registry integration with REST client and OpenShift certificate serving. Few differences:

• test native as well; what we want to test in native is:
  • certificates are picked up by Quarkus app in the native mode (that is TLS registry level, shared)
  • integration with OpenShift according to the TLS registry section https://quarkus.io/guides/tls-registry-reference#utilizing-openshift-serving-certificates (again, not relevant to specific client impl.)
• here it is tested that both HTTP server and REST client are configured with TLS version configured in TLS registry and they do require it

Please select the relevant options.

• Bug fix (non-breaking change which fixes an issue)
• Dependency update
• Refactoring
• Backport
• New scenario (non-breaking change which adds functionality)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[michalvavrik]

run tests

[mjurc]

Thanks a lot, LGTM

[michalvavrik]

run tests

[michalvavrik]

Native failed over Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching server.ts-jblpfaeiqm.svc.cluster.local found which is the original reason why I added untilAsserted. I think it is just flaky and we should add couple of seconds to waiting as it depends on OpenShift and not us. Let me add few seconds and retry.

[michalvavrik]

run tests

[michalvavrik]

yeah, OCP is green now so I'll merge it.

[fedinskiy]

FYI: our weekly runs now fail due to : java.security.cert.CertificateException

[michalvavrik]

FYI: our weekly runs now fail due to : java.security.cert.CertificateException

thanks, I'll look. this seems like OCP setup or longer waiting, I don't know what could change in code to avoid this, but let see

[michalvavrik]

in OpenShift they say that pod won't start until secret is mounted, so I think I need to inspect what is actually mounted in cases when it fails and whether it is retry or just randomness that is makes it sometimes fail and sometimes pass

[michalvavrik]

it's not quite easy to reproduce, didn't happen to me once so far :-( maybe it is more likely to happen when OpenShift cluster is busy, don't know.

[michalvavrik]

I figured it out: quarkus-qe/quarkus-test-framework#1296