Use Configuration.get_default_copy

[clive-jevons]

What do these changes do?

When loading the config from the load_incluster_config or load_kube_config methods
the result is stored in Configuration._default. We must then use the get_default_copy
method in order to retrieve a copy of the configuration containing the actually
config values previously loaded. Testest with kubernetes==12.0.0

Description

When creating a new Configuration instance using the constructor, the host always defaulted to http://localhost which resulted in the client not being able to connect if this is not what is actually configured in the kubeconfig.

With this change the loaded config is retrieved via the get_default_copy which then contains the configured values.

Only tested with kubernetes==12.0.0.

Type of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• [x ] The code addresses only the mentioned problem, and this problem only
• [x ] I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt

[nolar]

Some extra information for history:

The method was added to kubernetes here:

• kubernetes-client/python@b4d11b0#diff-977bedbaf9339b25749bc96a24266c1fa3e99ab521a835562fe84b2ab87b7001R197

And used there too:

• kubernetes-client/python@b4d11b0#diff-59aff6ce4d28aa662f8b411b9d0dfe4f3e949c32a5edaf8e08905b58e7a41ee3L69-R71

This commit has been released in kubernetes==12.0.0 the earliest, there are no older versions with it. The release was done 6 days ago (2020-10-15).

[nolar]

@clive-jevons Thanks for the contribution!

Assuming that Kopf does not keep kubernetes as a requirement in setup.py (on purpose: it is not "required", but only "used" if and when it is installed), what would be the best way to ensure that this method exists in the installed version of the client library in different setups/apps? E.g. if people have kubernetes==11.0.0 installed or pinned, and upgrade to kopf==0.29, where this PR is merged and released, which breaks the compatibility.

One option that I see would be to detect the version of kubernetes at runtime (not sure what is the easiest way), and warn/fail if it is <12.0.0. Another option is to check for the existence of the method and use it only if present, fall back to the class creation if absent.

What do you think?

[clive-jevons]

Agreed. And I think the checking for the method approach is probably best. Have adapted the PR accordingly 😁

[nolar]

Thanks! Merged. It will be released in late Oct or early Nov approximately (I'm now beautifying the main feature for the 0.29 release).

[clive-jevons]

Brilliant, thank you 🙏🏻😊