You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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...
The text was updated successfully, but these errors were encountered:
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
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
kubectl
and 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...
The text was updated successfully, but these errors were encountered: