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

DynamicResource should be replaced by DynamicObject #464

Closed
clux opened this issue Mar 17, 2021 · 2 comments · Fixed by #474
Closed

DynamicResource should be replaced by DynamicObject #464

clux opened this issue Mar 17, 2021 · 2 comments · Fixed by #474
Labels
api Api abstraction related

Comments

@clux
Copy link
Member

clux commented Mar 17, 2021

At the moment the api-discovery system in the client gives you DynamicResources in master.
However, to be turned into an Api, it goes thorugh:

pub fn try_into_api<K: Meta>(self, client: Client) -> Result<Api<K>>

i.e. it requires you having the type K already implementing Meta.
If we instead do this type of impls on DynamicResource, and construct the GVK behind the seems, it seems plausible to me that users can get an Api with a GVK family.

What do you think @MikailBag ?

@clux clux added the api Api abstraction related label Mar 17, 2021
@clux
Copy link
Member Author

clux commented Mar 17, 2021

Acceptance goals: dynamic_api example should be extendable so that we can add a dynapi.list() at every stage and print names of everything.
This would give us functionality like kubectl get all --all.

@MikailBag
Copy link
Contributor

it requires you having the type K already implementing Meta.

I think that kube::Api::DynamicObject should work as a K.
I've sent #466 to update dynamic_api example.

@clux clux linked a pull request Mar 24, 2021 that will close this issue
@clux clux closed this as completed in #474 Mar 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Api abstraction related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants