Access sub-resources

[cben]

Kubernetes APIs include many sub-resources. Currently Kubeclient ignores all of those in discovery and surprisingly we haven't seen much complaints.

This is a pre-emptive issue to collect whether there are any use cases for generic discovery support?

The actual API of sub-resources varies widely, and you can't know this from the discovery info :gift:

• Some sub-resources are pretty normal k8s CRUD, e.g. pods/{name}/status.

• Some are wildly different:

  • pods/{name}/proxy/{path} and friends for proxying / port forwarding into a pod. We presently offer Client#proxy_url and the rest is your problem...
  • pods/{name}/log for reading/streaming pod logs. We offer Client#get_pod_log covering most options.
  • POST to pods/{name}/eviction causes it to be evicted.
  • pods/{name}/exec opens websocket to stream stdin/stdout.

  and API extensions (at least ones implemented with via API aggregation) can offer varying sub-resource semantics too:

  • kubevirt has PUT to virtualmachines/{name}/restart restart a VirtualMachine object.
  • kubevirt has GET virtualmachineinstances/{name}/vnc Open a websocket connection to connect to VNC on the specified VirtualMachineInstance.

Conclusion?

So far, it sounds like generic discovery is pretty pointless, as one needs special-purpose code for each use case anyway? If anyone has counter-examples, please post here! That's my goal in opening this issue!

P.S. Method naming problem

One of the reason Kubeclient ignores sub-resource is it translates resources like pods to method names like get_pods, delete_pod etc. If we stop ignoring them, it's not obvious how to name methods.

[cben]

cc @shiramax. I believe your kubevirt VNC use case won't be helped by any generic sub-resource functionality, which this issue is about; but #417 (params to do your own connection) is more relevant for you.

[cben]

#422 wants to patch foo/status, and I think we should instead allow all verbs on foo/status.