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
When the cloud and edge are disconnected, and a List request is made for a registered CR, if the number of this custom resources is zero, normally, Yurthub should return an empty CRD List response, as follows:
But in fact, the error message is returned as follows:
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Internal error occurred: no matches for stable.example.com/v1, Resource=crontabs","reason":"InternalError","details":{"causes":[{"message":"no matches for stable.example.com/v1, Resource=crontabs"}]},"code":500}
What you expected to happen:
When the connection between cloud and edge is normal and the List operation is performed for CR, the corresponding CRD information should be saved even if the number of resources is empty.
When the cloud and edges are disconnected, and a List request is made for an empty number of CR resources
If CRD is registered , empty structure will be returned
If CRD is not registered , an error message will be returned
How to reproduce it (as minimally and precisely as possible):
Register a CRD but do not create any resources
When the communication between the cloud and the edge is normal, make a list request for this CR
You will get the correct reply message with empty list structure
When the cloud and the edge are disconnected, make a list request for this CR resource
What happened:
When the cloud and edge are disconnected, and a List request is made for a registered CR, if the number of this custom resources is zero, normally, Yurthub should return an empty CRD List response, as follows:
But in fact, the error message is returned as follows:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
kubectl version
):cat /etc/os-release
):uname -a
):Linux master 3.10.0-1160.25.1.el7.x86_64 #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
others
/kind bug
The text was updated successfully, but these errors were encountered: