Ability to mutate single client to switch api group/version

[kuahyeow]

overview of alternatives: #208 (comment)

Currently in order to access api endpoints from another api group, we have instantiate a new Client object

client = Kubeclient::Client.new('http://localhost:8080/apis/rbac.authorization.k8s.io', 'v1')

Is there a way to reset the api_endpoint of a pre-existing Client ? E.g.

client = Kubeclient::Client.new('http://localhost:8080/api/', "v1")
client.get_service_accounts

client.api_endpoint = 'http://localhost:8080/apis/rbac.authorization.k8s.io'
client.get_role_bindings

[cben]

Not currently. It's a known pain-point.

Was discussed a lot in #208, #241 and several other places. Most previous discussion was towards allowing one client object to represent a "union" of methods from several api groups.
The mechanism you propose here, also proposed in #329 (comment), is somewhat different — only one group is active at a time, and you can mutate it. So let's use this issue for this variant (I took the liberty to change the title).

[cben]

I'll say right out that I don't like the mutation idea 😟
The way I see it, a client object is not just something you need to perform the actions. It's what you pass around in your code to represent a specific cluster & settings.
But the way k8s apis evolve, you typical need to mix several API groups, pretty arbitrarily, in same code that works on one cluster. (I think we all agree so far)

Now consider this code:

def example_function(client)
  client.list_pods
  call_sub_function(client)
  client.create_service(...)
end

As it happens, this code only needed one group/version (say core v1), so it never bothers to declare "now I'm switching to core v1", it just assumes it got a suitable client.
Now the problem with mutation, is that just the act of passing same client to different code that does need to switch groups, and then calling example_function() again would break it.
=> If we go this way, ALL code receiving a client should start by switching group, just to be sure ☹️

I think the implementation would not be significantly easier than a safer "union" client (you need to redo discovery on every switch, or better cache discovery results and methods from previous groups).

I'll do a summary of other directions on #208.

[kuahyeow]

Thanks @cben

I do prefer a "union" client or a client that can query the combination of all api groups. 👍

In the absence of such a client, I was hunting for a work-around in the mean-time.

[cben]

This would also be very not thread safe (#419).
Closing this one as nobody actually preferred this option, and it won't be simpler to implement then others. (If anyone disagrees, speak up / reopen.)