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

[feature request]all resources can be cached by yurt-hub #162

Closed
rambohe-ch opened this issue Dec 1, 2020 · 6 comments · Fixed by #225
Closed

[feature request]all resources can be cached by yurt-hub #162

rambohe-ch opened this issue Dec 1, 2020 · 6 comments · Fixed by #225

Comments

@rambohe-ch
Copy link
Member

What would you like to be added:
only resources in the resourceToKindMap can be cached by yurt-hub component, and this a limitation. yurt-hub should cache all kubernetes resources, including crd resource that defined by user.

Why is this needed:
when network between cloud and edge disconnected, if any pod(eg: calico) on the edge node that used some resources(like crd) not in the above map want to run continuously, that is to say, the pod can not restarted successfully because resources(like crd) are not cached by yurt-hub.

@vincent-pli
Copy link
Member

@rambohe-ch
Does this means we do not need to keep the list for cache all the resources?

@rambohe-ch
Copy link
Member Author

@rambohe-ch
Does this means we do not need to keep the list for cache all the resources?

@vincent-pli yeah, the list(resourceToKindMap) will not be used to verify the resource that can be cached or not.

@GsssC
Copy link

GsssC commented Jan 6, 2021

We use resourceToKindMap is because the obj misses the field of apiverison and kind.

The reason why obj misses the field of apiverison and kind is yurthub using serializer.WithoutConversionCodecFactory as NegotiatedSerializer, which produces WithoutVersionDecoder and remove the apiversion/kind of object when serialized from http.resp.

Change the NegotiatedSerializer may solve.

@qclc (Chen Tao) how about dig more to find a WithVersionCodecFactory as NegotiatedSerializer?

@rambohe-ch PTAL.

@rambohe-ch
Copy link
Member Author

We use resourceToKindMap is because the obj misses the field of apiverison and kind.

The reason why obj misses the field of apiverison and kind is yurthub using serializer.WithoutConversionCodecFactory as NegotiatedSerializer, which produces WithoutVersionDecoder and remove the apiversion/kind of object when serialized from http.resp.

Change the NegotiatedSerializer may solve.

@qclc (Chen Tao) how about dig more to find a WithVersionCodecFactory as NegotiatedSerializer?

@rambohe-ch PTAL.

@GsssC i think it is a good answer, and i am look forward to your proposal @qclc

@GsssC
Copy link

GsssC commented Jan 15, 2021

@rambohe-ch yeah,besides,client-go scheme do not support decode cr request,we do need a specially designed nogotiatedSerializer to offer both normal serializer for resource that has been registered in client-go scheme(json protobuf yaml), and serializer(indeed, a json serializer) for unregistered resource like cr.

@qclc
Copy link
Member

qclc commented Feb 23, 2021

I added WithVersionCodecFactory instead of serializer.WithoutConversionCodecFactory. Solved the issue of GVK information loss when decoding built-in resources.
This PR extends the ability to cache CR resources, removing the restriction that only resources in resourceToKindMap and resourceToListKindMap can be cached, but the general serialization and deserialization capabilities for CR resources are still under development.
The PR is in #225 , please review my code, and give some suggestions. @rambohe-ch @GsssC
I will submit the corresponding proposal later to show how to encode and decode general CR resources to achieve the purpose of caching CR resources.

qclc added a commit to qclc/openyurt that referenced this issue Mar 1, 2021
qclc added a commit to qclc/openyurt that referenced this issue Mar 2, 2021
qclc added a commit to qclc/openyurt that referenced this issue Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants