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.

from kubeclient.

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

from kubeclient.

cc @moolitayer

from kubeclient.

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.

from kubeclient.

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.

from kubeclient.

(@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.

from kubeclient.

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

from kubeclient.

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.

from kubeclient.

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.

from kubeclient.

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.

from kubeclient.

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

from kubeclient.

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?
  • #241 attempted to magically autodetect one version for each group. (it also did other things, including #332).
  • #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...
• #346 allow to switch client object to different api group/version (losing previous group).
• #347 a method to obtain related client from any existing one — everything same except group/version.
• #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.

from kubeclient.