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
Adding application specific properties to Robot CRD could overload this CRD over the time.
We should find a more flexible way to transport those data in the future
We are also discussing to maybe rename the crd to onprem to highlight that the construct is there to support the hub-spoke pattern of a master cluster that had n children associated. Which of the onprem clusters is a robot or eg an onprem cache node can be established by using labels.
Not sure if it makes most sense to also have the robot crd to support your use cases in parallel or what would be a better way to provide the status information instead.
It sounds reasonable to rename the Robot CRD. I have the same understanding of the use case pattern as you have.
I would prefer naming it "edge". This sounds a bit industrial IoT alike. Edge could be in a plant next to a machine, on a robot, in a server room or maybe on am offshore platform.
In our terms "onprem" means something like "not in the cloud but still in an (own) datacenter".
Concerning the question of how to proceed with the robot CRD. I like the idea of sharing information between the clusters. A property like trolleyAttached is probably too specific for a use case, but defining common properties of a robot like status and maybe batteryPercentage could be useful. If there is a new CRD to represent the children it would be safe opening robot CRD for that, because you don't risk screwing up platform functions like AppRollout.
Adding application specific properties to Robot CRD could overload this CRD over the time.
We should find a more flexible way to transport those data in the future
Follow up to our discussion in pull request #41
The text was updated successfully, but these errors were encountered: