dealing with api/v1 vs apis/extensions/v1beta1 is annoying since they are split between url and version

[grosser]

url should be everything without the /api ... and version should be either api/v1 or maybe just v1 / extensions/v1beta1 and then smartly detect if it should be api or apis

atm I'm using this which is kinda wonky

  def client(version)
    (@client ||= {})[version] ||= begin
      path, version_number = version.scan(/(.*)\/(\S+)$/).first
      Kubeclient::Client.new(
        "#{@url}/#{path}",
        version_number,
        auth_options: (testing? ? {} : { bearer_token_file: BEARER_TOKEN_FILE }),
        ssl_options: (testing? ? {} : { ca_file: CA_FILE }),
        timeouts: {open: 2, read: 10}
      )
    end
  end

[cben]

Right! Here's our similar code, also spliting on /: https://github.com/ManageIQ/manageiq-providers-openshift/blob/93009fcb167/app/models/manageiq/providers/openshift/container_manager_mixin.rb#L40-L52

1. Any idea if this can be backward compatible?
2. Does this interact with #208? I this would be a first step to make multi-version use by multiple Client instances a tiny bit less annoying, and doesn't affect/depend on ideas for multi-version with one instance...

[grosser]

I'd love to have multi-version in a single client too, so you can pass the version as an option, but that can be step 2 ... to be backwards compatible it could just blow up if the url has a path or store the url path as version_base and then not override it when present

On Thu, Jan 11, 2018 at 11:47 AM, Beni Cherniavsky-Paskin < [email protected]> wrote:

Right! Here's our similar code, also spliting on /: https://github.com/ManageIQ/manageiq-providers-openshift/ blob/93009fcb167/app/models/manageiq/providers/openshift/ container_manager_mixin.rb#L40-L52

1. Any idea if this can be backward compatible?
2. Does this interact with #208 https://github.com/abonas/kubeclient/issues/208? I this would be a first step to make multi-version use by multiple Client instances a tiny bit less annoying, and doesn't affect/depend on ideas for multi-version with one instance...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/abonas/kubeclient/issues/284#issuecomment-357040359, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAsZzZqOe-Ziubam5DgdNHQThGTUfFzks5tJmU1gaJpZM4RZ3n7 .

[cben]

For anyone tackling this: the tests added in #457 are a good starting point. We should still support everything these tests cover, for compatibility.

However, if it makes things easier, can have new keyword params for new behavior, supporting only one scheme. Something like

Kubeclient::Client.new(
  # Exactly what you get from `config.context(...).api_endpoint`.
  # No /api, /apis, /oapi allowed.
  endpoint: "http://example.com/k8s/clusters/c-somerancherID",  

  # Exactly the `apiVersion` in the JSON representation for resources you want to access.
  # (One should NOT pass here `config.context.api_version` which is version of kubeconfg file, 
  #  see commit c593c9eef58e56f00c396f4715437eed673ca98e).
  # Would `group:` can be a clearer name then `api_version:`?
  api_version: "autoscaling/v1",

  ssl_options: config.context.ssl_options,
  auth_options: config.context.auth_options
)