lsergio commented on issue #5179:
URL: https://github.com/apache/camel-k/issues/5179#issuecomment-1971831095
@lburgazzoli After reaching to some people here, I found the root cause...
Kubernetes is injecting environment variables into any pod with metadata
based on the services that are running, as in:
```
APIM_CONNECTOR_C2228101_CF6A_4B3E_B502_62C99359A799_SERVICE_PORT=tcp://172.20.203.161:80
APIM_CONNECTOR_08BFC757_3D93_419A_8182_390B77D62DB1_SERVICE_PORT_80_TCP=tcp://172.20.206.40:80
APIM_CONNECTOR_08BFC757_3D93_419A_8182_390B77D62DB1_SERVICE_PORT_80_TCP_ADDR=172.20.206.40
```
That's not enough to explain the CAMEL_COMPONENT variables.
But then we found that a developer was also testing Camel components using
Camel K and created an integration named "camel-component-test".
This created a camel-component-test service that was active when the
operator started, and thus explains the weird env vars.
When I tested using the pod strategy it didn't fail because the the
camel-component-test service is no longer running.
So now everything is running fine again and I advised everyone about not
using camel-* names.
Thanks a lot for the guidance, @lburgazzoli.
I think we can close the ticket now and I'll remove the bug label.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
