We have implemented operator (controller) using quarkus version: 2.16.3.Final, quarkus-operator-sdk version: 5.1.0 .
When application is deployed to OpenShift cluster from within pod it correctly detect OpenShift internal API URL and token.
Then we upgrade app to quarkus version: 3.5.0, quarkus-operator-sdk version: 6.4.0.Beta1.
When application is deployed to OpenShift cluster from within pod, in our opinion, it wrongly detect OpenShift API URL and instead use of OpenShift internal API URL (https://openshift.default.svc.cluster.local) it trying to use external (e.g. https://api.my-external.cluster.dns.name:6443). In our case we get timeout exception because of firewall on our external API load balancer.
We could fix our firewall whitelisting but we think that application hosted on OpenShift cluster should primarily use OpenShift internal API URL (more optimized) instead of network wise exit cluster got through load balances and then come back to internal network and hit API.
Our current workaround is setting environment variable to deployment
Hi,
We have implemented operator (controller) using quarkus version: 2.16.3.Final, quarkus-operator-sdk version: 5.1.0 . When application is deployed to OpenShift cluster from within pod it correctly detect OpenShift internal API URL and token.
Then we upgrade app to quarkus version: 3.5.0, quarkus-operator-sdk version: 6.4.0.Beta1. When application is deployed to OpenShift cluster from within pod, in our opinion, it wrongly detect OpenShift API URL and instead use of OpenShift internal API URL (https://openshift.default.svc.cluster.local) it trying to use external (e.g. https://api.my-external.cluster.dns.name:6443). In our case we get timeout exception because of firewall on our external API load balancer.
We could fix our firewall whitelisting but we think that application hosted on OpenShift cluster should primarily use OpenShift internal API URL (more optimized) instead of network wise exit cluster got through load balances and then come back to internal network and hit API.
Our current workaround is setting environment variable to deployment
So maybe this is bug or behavior change.
Thanks.
Regards, N.
p.s. OpenShift cluster v4.12