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

List of third party resource objects #1671

Closed
maciaszczykm opened this issue Feb 23, 2017 · 1 comment
Closed

List of third party resource objects #1671

maciaszczykm opened this issue Feb 23, 2017 · 1 comment
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@maciaszczykm
Copy link
Member

maciaszczykm commented Feb 23, 2017

Backend for listing TPR templates (using "template" term to distinguish them from "objects") is already merged, frontend should be soon (#1649). Right now I'm working on adding list of objects to template details as it was planned in #1504. kubernetes/enhancements#95 (comment) tells us, that there are a lot missing functionalities. There are few things worth mention.

Different API version groups for each TPR

The REST API semantics for get, list, watch, update, and patch are not defined for handling multiple versions. Since TPRs cannot convert from one version to another, even handling things as simple as a GET for foo.v2.tpr.group if its stored as foo.v1.tpr.group is undefined.

It forces us to dynamically create clients for each API version group like it's shown here:

https://github.com/kubernetes/client-go/blob/master/examples/third-party-resources/main.go#L148

I'm still trying to figure out the best solution to list all objects for types and not to create clients for each call. The best case scenario is using most of Kubernetes logic in Dashboard backend. Have to take a look at kubectland check if they've done it.

TPR types registration

It would be the best to load objects into structures instead of working with raw responses. It's easy to register one type, but in Dashboard we need to handle all types that users will create.

To be continued...

@maciaszczykm maciaszczykm added area/api kind/feature Categorizes issue or PR as related to a new feature. labels Feb 23, 2017
@maciaszczykm maciaszczykm self-assigned this Feb 23, 2017
@maciaszczykm
Copy link
Member Author

Moved discussion to #1676.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

1 participant