ManageIQ/kubeclient

Ability to add api groups to existing client

cben opened this issue · 3 comments

cben commented

overview of alternatives: #208 (comment)

A variant of "union" client #208, #241:
Many people want one client object to combine methods from multiple API groups. The main questions are: union of what groups, which version per group, and who wins method name collisions?

This proposal is that Kubeclient would not try to guess. User would start from one group, and be able to add them one by one, each with specific version:

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

client.add_group('rbac.authorization.k8s.io/v1')
client.get_role_bindings

many people would add all desired groups when constructing client, and then just have the ability to call all methods:

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

client.get_service_accounts
client.get_role_bindings

Method name collisions would be decided by order of addition. Not sure if latest or earliest wins?

I think this can solve some concerns with #241.
It also can work better with CRDs that might appear dynamically, after client exists.

Why not do something like

client.api('rbac.authorization.k8s.io/v1').get_groups

Or (because how often do you really switch)

client.setApi('rbac.authorization.k8s.io/v1')
client.get_groups()
client.setApi('some.other.api')
client.someOtherMethod()

Adding the possibility to add many groups IMHO creates unnecessary complexity.

cben commented

client.api('rbac.authorization.k8s.io/v1').get_groups

I think that's #347.

client.setApi('rbac.authorization.k8s.io/v1')
client.get_groups()
client.setApi('some.other.api')
client.someOtherMethod()

that's #346. Trying to keep one issue per approach to focus discussion :)

EDIT: see #208 (comment) for bigger overview

There's a convenience tradeoff — for many use cases you can add_group all you need near construction and then you don't need to mention groups anywhere else.
Many people asked for some form of "union" client.
Implementation may be harder (which is one reason it's not yet here) but I think once we agree on best interface & behavior, it'll go smoother. #241 did lots of great stuff, run into disagreements more than technical issues...

cben commented

Also worth mentioning I think we need #332 anyway.
it'll expose a way — though quite different and perhaps less friendly — to use one client with many groups, something like:

client.list(kind: 'Group', apiVersion: 'rbac.authorization.k8s.io/v1')

which maybe makes some approaches like #347 less of a win (?)