Fabric8 Kubernetes Client system properties and environment variables should be ignored.

[iocanel]

Describe the bug
Currently, environmnet variables like KUBERNETES_MASTER are picked up by the kubernetes-client possibly causing issues that are really hard to troubleshoot.

Expected behavior
All internal variables to fabric8/kubernetes-client should be ignored and only properties passed via quarkus should be used.

Actual behavior
fabric8/kubernetes-clinet internal variables and properties are picked up.

To Reproduce
Steps to reproduce the behavior:

1. Configure .kube/confg to point to the desired cluster
2. Set KUBERNETES_MASTER pointing elsewhere
3. Use the client without explicit configuration

The client will use KUBERNETES_MASTER.

** Possible soltuion **
AFAIR fabirc8/kubenretes-client provides feature flags for system proerties and env configuration. We need to turn them offf in the kubenretes-client extension.

[quarkusbot]

/cc @geoand

[geoand]

This would be a breaking change for people that already rely on the feature

[iocanel]

Yeah, but it's a feature not documented and not intended. So, I seriously doubt if anyone does use it intentionally.

[geoand]

Yeah I agree. We just need to warn folks

[Ladicek]

How come this is not intended? If it's a feature of Fabric8 Kubernetes client, and we advertise we use Fabric8 Kubernetes client, then we naturally expose its features, no?

[geoand]

I think @iocanel had someone report some kind of related error.

I was thinking about this, and I think that if we are going to do this, we should (via Quarkus config) be able to control whether or not the Client's natural wau of configuring itself will come into play or not

[geoand]

Looking at the source of the client, I don't see a way of not taking system props or env vars into account, but I may be missing something.

[geoand]

Is this something that has been added to the client recently @iocanel / @manusa ?

[manusa]

There is the Config#empty() which prevents inferring any kind of configuration from the system.

I'm not sure if this is what you're asking.

However, when using this configuration everything would need to be configured manually (maybe by reusing some methods such as Config#fromKubeconfig)

[manusa]

I feel more like Ladislav, I don't see this as an issue (maybe the lack of documentation or of information is).

We have the same behavior in Eclipse JKube, if a user needs to override some settings when dealing with a cluster, the use of system properties is an option.

[geoand]

I'll leave up to you folks to figure out whether this will be implemented or closed as won't fix

[geoand]

@iocanel I think we can close this as we never acted on it and no one complained in the meant time.