Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Api<PartialObjectMeta<K>> should opportunistically degrade to metadata requests #1614

Open
nightkr opened this issue Oct 23, 2024 · 2 comments
Labels
api Api abstraction related core generic apimachinery style work runtime controller runtime related

Comments

@nightkr
Copy link
Member

nightkr commented Oct 23, 2024

Would you like to work on this feature?

None

What problem are you trying to solve?

Currently we have two APIs for querying metadata:

  1. Api<K>::get_metadata (and co)
  2. Api<PartialObjectMeta<K>>::get (and co)

Currently, 1 requests that the K8s API only sends the metadata, while 2 requests the whole object and then discards everything else during deserialization. This requires every API to have separate variants to handle metadata-only requests efficiently (and not all of them have that path, like https://docs.rs/kube/latest/kube/runtime/struct.Controller.html#method.watches).

Describe the solution you'd like

Api::get (and co) should recognize metadata-only types, and automatically switch to the fast path.

Describe alternatives you've considered

We could continue threading both variants through all APIs that take an Api.

Documentation, Adoption, Migration Strategy

This should be transparent for end users: if you use the existing API then things just get more efficient.

Target crate for feature

kube-client

@nightkr
Copy link
Member Author

nightkr commented Oct 23, 2024

One way to detect this would be to add a

const fn is_meta_only() -> bool { false }

to kube::Resource, implement it as true for PartialObjectMeta, and then match on that.

@clux
Copy link
Member

clux commented Oct 23, 2024

Ah, nice idea. A Resource level setup for this would let us get rid of / deprecate the whole metadata_watcher setup as well, since we can then just rely on the opportunism down the stack.

maybe:

/// Resource uses the metadata api
///
/// Forces use of `Request::get_metadata`, `Request::watches_metadata`, `Request::list_metadata`
/// in place of `Request::get`, `Request::watches`, `Request::list`.
const fn metadata_api() -> bool { false }

@clux clux added runtime controller runtime related api Api abstraction related core generic apimachinery style work labels Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Api abstraction related core generic apimachinery style work runtime controller runtime related
Projects
None yet
Development

No branches or pull requests

4 participants
@clux @nightkr and others