Open clux opened 2 years ago
We might also consider the metadata-only API to be included on the Client
type.
Another extension discussed in the discord that's possible with query methods on Client
: dynamic get lookups from ObjectRef
:
fn get_by_ref<K>(oref: &ObjectRef) -> Result<K>
# or if following get_opt and catching the 404
fn get_by_ref<K>(oref: &ObjectRef) -> Option<Result<K>>
then users can pick K
as DynamicObject
or whatever Resource
type they might know they are looking up for.
We could add nice converters to more easily construct ObjectRef to simplify working with these.
What problem are you trying to solve?
To use any part of the Kubernetes api on a
Resource
you currently have to instantiate anApi
object. In many cases, this abstraction saves some time by giving the user a type bound to a resource that you can do multiple queries on (within the same scope), but in many other instances it leads to lots ofclient.clone()
calls to create throwawayApi
instances that are used for a single query. We see this all the time in reconcilers.We see users working around it by implementing these things more or less directly on the
Client
themselvesIt also leads to problems where people create an
Api::all
to perhaps query across all namespaces, and legitimately ending up with an "illegal" way to create a namespaced resource. See #1030It's also not the first time this idea of avoiding
Api
has been floated around: https://github.com/kube-rs/kube/pull/594. But I think we can do this in a non-breaking way, without having to rewrite so much as the original PR attempted to do (though there are some great simplifications in there).Describe the solution you'd like
We should implement these methods directly on client:
and near identical impls for
ClusterResourceScope
but without the ability to do anything namespaced (basically the same fn interfaces as onApi
since they don't take a namespace.The function bodies should leverage kube-core's
Request
objects and be functionally equivalent to theApi
method's parallels, but without having to read namespace fromself
and instead get it from some newtype (to avoid two string args in a row).Describe alternatives you've considered
We could hide some of this behind an async trait to make this stuff mockable, but then we would need to pull in
async_trait
(which we currently do not). Not sure what is the best solution for this. Is it a problem to have a bunch new pub methods onClient
?Documentation, Adoption, Migration Strategy
We don't need to deprecate
Api
I think. The abstraction is useful, just not nearly as universal as originally envisioned. However, this does mean that more ofruntime
can create some of itsimpls
directly onClient
in a less or more constrained way. This might be nicer in some places, but it might be more problematic since we now force dealing with scope down to the resource.To minimize the amount of code-duplication within kube-client, we could make the methods on
Client
canonical, and makeApi
a more empty shell that defers to these.Less sure what to do about the subresource scope though. That requires some thought.
Target crate for feature
kube-client
Future Ideas
Future things that should be considered later on (open follow-ups):
Implementation Plan
WIP:
Client::list
+Client:get
- https://github.com/kube-rs/kube/pull/1375Client::delete
+Client::delete_collection
Client::patch
Client::patch_status
+Client::patch_status_namepaced
and decide whether to make a typed variant (so you can take theStatus
object - e.g. https://github.com/kube-rs/kube/discussions/1465)