Expose url, headers, auth options for handoff to other HTTP clients?

[cben]

This would be a second "escape hatch" beyond #389, for cases when one needs to connect to particular API over another gem / language / out of process.

Turns out it's now hard to grab url / http headers / TLS auth out of a Kubeclient::Client objects, using public interface 😞.

Undocumented internal interfaces, will change: Client#http_options includes options and headers in suitable form for http gem; Client#rest_client creates rest-client gem instance but without headers, so one also needs @headers 😕

Can we make that easier?
Should we, or should one instead directly ask Config objects?

Motivation examples: Websockets

• kubectl exec No way to do the equivalent of kubectl exec? #353 transports stdin/stdout over websocket.
  Note how the proof-of-concept gist extended Client class to gain access to internals!
  (This specific functionality could plausibly become part of kubeclient, but the point is, it's hard using public API only)

• kubevirt has custom API extension with a sub-resource virtualmachineinstances/{name}/vnc serving VNC over websockets. [implementation]
  @shiramax wants to proxy it to a browser VNC client, where the proxying is possibly implemented out-of-process (there is a suitable python proxy?)
  In any case, need to extract URL and headers.

Points that need care

• Adding a method to return server's base URL is easy.

• Exposing specific API group's URL is easy now but what will it mean in future when we'll want one Client to cover multiple groups (Ability to add api groups to existing client #348 seems to be most desired direction)?

  • Exposing specific sub-resource's URL

• Adding a method returning hash of HTTP headers, including Authentication, is easy.

• But remember that TLS client certs are also an auth option!
  Do we need extra methods to return client certs?
  Do we need single method to return {headers + TLS options} in one package?

• In future we'll want to support authentication renewal Authentication renewal #393, so one should be careful to ask for fresh headers + TLS options every time!

Does this belong in Client or Config?

This interface would be more informational than actions.

The interface design questions here are remarkably similar to the open questions from auth renewal #393.

They're even more related to the idea of extracting something similar to Config to a shared gem to be used by kubeclient, kubernetes-client, k8s-client 🙏
Hey — if we find an interface for parsing kubeconfig / obtaining auth that 3 different gems could use, than hopefully You could use it too for whatever custom connection You need...

=> So my default assumption is (1) this belongs in Config (2) the long game here is not invest in this directly but figure a good standalone config/auth interface...

However I'm open to PRs that'd plug current pain points even if not in "perfect place" 👍

[cben]

I'm closing on assumption that using Config is the best answer for now. If anyone feels otherwise, feel free to re-open / send PRs.