Is configuration global?

[cben]

Looking at Kubernetes.configure or Kubernetes.load_kube_config examples in the docs, it seems configuration is global for the gem.
And then one can do parameter-less api = Kubernetes::CoreV1Api.new; api.list_pod_for_all_namespaces.
This is convenient for common case, but does it preclude connecting to several clusters at same time with different auth?

Hmm, it seems CoreV1Api.new etc can take an ApiClient instance. And you can produce ApiClient from a Configuration:
https://github.com/kubernetes-client/ruby/blob/7f268172b/kubernetes/lib/kubernetes/utils.rb#L47
needs more docs...

[cben]

Followup question: docs don't explain what's the purpose of separate api = Kubernetes::CoreV1Api.new step.

• Is there performance drawback to doing Kubernetes::CoreV1Api.new.list_pod_for_all_namespaces for every call? Is it important to reuse api group objects?
• Is it simply a pattern that's close to what works well with separate clients:
  api = Kubernetes::CoreV1Api.new(api_client); api.list_pod_for_all_namespaces ?

Let's see, if we have several clusters and want to talk to several api groups in each.
A typical piece of code (say a function) will talk to one cluster, given as parameter, but is likely to mix several api groups (given how k8s apis evolve, starting out as alpha, and nowdays most not even destined into core...).
Then my instinct is for the function to take an ApiClient parameter. I want one thing to pass around, don't want to pass a bunch of api group objects. This limits ability to reuse group objects across functions / refactorings, so I might as well give it up.
=> Doing Group.new(client).method for every call, e.g.:

CoreV1Api.new(api_client).list_pod_for_all_namespaces
AutoscalingV1Api.new(api_client).create_namespaced_horizontal_pod_autoscaler(...)

actually sounds like path of least resistance...

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cben]

To answer myself:

• Indeed, helpers like Kubernetes.configure affect the singleton Configuration.default used by ApiClient.new(), memoized as ApiClient.default and used by group classes by default e.g. CoreV1Api.new(). This is just a convenience.

• For the multi-config use case, producing ApiClient from a Configuration is now documented in README and a couple examples.

• The style of passing around an ApiClient rather then group objects and doing Group.new(client).method wherever you actually need to do something seems legit. All group classes have trivial constructor:

    def initialize(api_client = ApiClient.default)
      @api_client = api_client
    end