Skip to content

KubernetesProfileEnvironmentPostProcessor should be conditional on spring.cloud.kubernetes.enabled #420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
stefanocke opened this issue Jul 1, 2019 · 3 comments · Fixed by #421

Comments

@stefanocke
Copy link

stefanocke commented Jul 1, 2019

Several configuration classes like KubernetesAutoConfiguration and KubernetesDiscoveryClientAutoConfiguration are condtional on spring.cloud.kubernetes.enabled.
This allows to "switch off" kubernetes client completely in non-k8s environments.

But, KubernetesProfileEnvironmentPostProcessor is currently not conditional.
So, it always runs and for example creates a DefaultKubernetesClient which in turn can lead to k8s-related warnings, for example in io.fabric8.kubernetes.client.Config.tryServiceAccount

In my case, I have seen the following:

Error reading service account token from: [/var/run/secrets/kubernetes.io/serviceaccount/token]. Ignoring.

It would be nice to have KubernetesProfileEnvironmentPostProcessor conditional on spring.cloud.kubernetes.enabled, too, to avoid that kind of warnings in non-k8s enironments.

@geoand
Copy link
Contributor

geoand commented Jul 1, 2019

Thanks for opening the issue.

Can you please provide the entire log line?
I am thinking perhaps we need to change the logging level since I don't think we can't really turn off the post processor

@stefanocke
Copy link
Author

@geoand , the complete message is the one above. It is from io.fabric8.kubernetes.client.Config.tryServiceAccount.

I think, the logging level there is quite appropriate. (And btw, it is not in spring-cloud-kubernetes anyway.)
Why not to turn off the PostProcessor in a situation where Kubernetes Client shall be switched off completely?

@geoand
Copy link
Contributor

geoand commented Jul 1, 2019

@stefanocke yeah, makes sense. I opened #421

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants