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 https://github.com/quarkus-qe/quarkus-test-framework/pull/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
• [x] New scenario (non-breaking change which adds functionality)
• [ ] This change requires a documentation update
• [x] This change requires execution against OCP (use run tests phrase in comment)

Checklist:

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

[michalvavrik]

run tests

[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: https://github.com/quarkus-qe/quarkus-test-framework/pull/1296