Allow different resources to use different apiVersion

[garo]

Currently the apiVersion is set on the Kubeclient::Client.new and it's enforced in https://github.com/abonas/kubeclient/blob/master/lib/kubeclient/common.rb#L320

We should instead allow that the resource contains apiVersion by itself and Kubeclient should honour that. This would allow easily to read a standard Kubernetes manifest .yaml file and apply that into the apiserver, so that the .yaml specifies the api version it requires.

[jeremywadsack]

Is that needed anymore? It was commented as a patch for kubernetes/kubernetes#6439, which according to comments on that issue has a commit that addresses it.

Also, +1 for not having to tie the client to a specific API version and endpoint, but allowing a single instance of the client to create resources for different manifest types.

[salilgupta1]

Is this anywhere on the roadmap? It would be great to decouple the client from a specific API version

[simon3z]

cc @moolitayer

[moolitayer]

Not currently on my road map.

Designing the API (as well as backward compatibility) for this might prove somewhat complex.
for example this proposal describes put requests, but what is the plan for get, will we still enforce passing a version in initialization and use that?

I remember last time we discussed that, we had an idea of supporting some set_version which seems easier but might not support what is described here

I don't think I'll be investing time in this anytime soon since it is not needed for my usecases
(@zakiva my say otherwise, aka template initialization of different versions)

if @simon3z will be willing to accept a pr for this I will be willing to review.

[simon3z]

if @simon3z will be willing to accept a pr for this I will be willing to review.

I'd like to see how the design/api would look like before anyone investing into it.

[zakiva]

(@zakiva my say otherwise, aka template initialization of different versions)

For the use case of template instantiation, we just create different clients according to the api and version we need. It could have been a little more elegant to use the same client with different versions, but I wouldn't consider it as a high priority item for us in this context.

[jeremywadsack]

It seems to me that on the all requests (including GET requests) you still have methods for each resource so maybe you can look up the default ApiVersion for a resource?

It would be nice to not have to have multiple clients. This pattern feels cumbersome:

      def jobs_client
        @jobs_client ||= client("/apis/batch")
      end

      def pods_client
        @pods_client ||= client("")
      end

      def clean_up
        jobs = jobs_client.get_jobs(label_selector: "resque-kubernetes=job")
        finished_jobs = jobs.select { |job| job.spec.completions == job.status.succeeded }

        finished_jobs.each do |job|
          jobs_client.delete_job(job.metadata.name, job.metadata.namespace)
        end

        pods = pods_client.get_pods(label_selector: "resque-kubernetes=pod")
        finished_pods = pods.select { |pod| pod.status.phase == "Succeeded" }

        finished_pods.each do |pod|
          pods_client.delete_pod(pod.metadata.name, pod.metadata.namespace)
        end
      end

[garo]

I had to do a similar system where I create multiple clients for different api/extension versions and then try to find out the suitable client which supports a particular entity type.

It would be really great if kubeclient would just transparently support all different api versions with a single client instance.

[simon3z]

It would be really great if kubeclient would just transparently support all different api versions with a single client instance.

@garo OK for creation and update of resources (above request doesn't apply to getting resources).
It shouldn't too hard to submit a PR for that (creation/update).

Although be advised that if the different api versions are changing the URL paths, that case we may not be able to handle so easily.

[danajp]

Hey all. I've opened a PR to make multiple apis with a single client instance work as well as detecting kind/apiVersion from a KubeClient::Resource. This is definitely WIP.

I'm looking for feedback on the approach at this point. If my general approach looks good, I'll continue with tests/cleanup.

[simon3z]

Thanks @danajp! I asked @moolitayer and @cben to review your WIP PR.

[cben]

Overview of directions

Opened separate issues for several proposed directions, for easier discussion. (cc @stiller-leser @kuahyeow)

• "Union" client as discussed here, with methods from many groups. The main questions are: union of what groups, which version per group, and who wins method name collisions?
  • Support multiple apis, detect kind/apiVersion #241 attempted to magically autodetect one version for each group. (it also did other things, including Expose {create,delete,...}_entity methods to manipulate objects of dynamic kind #332).
  • Ability to add api groups to existing client #348 Start with one group, allow to add more groups to same client.
  • mix-them-yourself: kubeclient would do one group per object, but expose discovery as a mixin (ruby Module), allowing you to build a union client yourself...
• Ability to mutate single client to switch api group/version #346 allow to switch client object to different api group/version (losing previous group).
• Ability to obtain related client for different api group/version from existing client #347 a method to obtain related client from any existing one — everything same except group/version.
• Expose {create,delete,...}_entity methods to manipulate objects of dynamic kind #332 Expose a lower-level API that takes a resource with kind and apiVersion.
  The motivation is separate, but as it happens, such API would also support any group/version from one client! Would need to rewrite code in very different style to take advantage of it.

What do you think?
IMHO #348 can be better than #241 & #346.
But #332 needs to happen anyway, is simple, and provides good foundation so that's IMHO best place to start.