@mhl787156 about the discovery server user-experience problem, probably we can use kubernetes service discovery, not application runtime layer. using headless service for discovery server, and describe that service information in deployment, that would work. in that case, user application does not really need to know anything about this, but can use service discovery.
@tomoyafujita oh that sounds like a good idea, so far i’ve tried to use kubernetes as is (the hurdles of doing anything remotely complex are daunting!) but if we could wrap the discovery server as a kubernetes service discovery mechanism that would be really neat. It would solve a whole bunch of networking problems too!
This combined with Custom Resource Definitions, it almost sounds like we should be building a ROS dedicated kubernetes stack, instead of simply using k8s!
My presentation is here for future reference : Nextcloud
Was the presentation recorded in the end?
@tomoyafujita the only sad thing is that we end up reverting back to the ROS1 way of doing things. This really is the downside of doing full multi-robot ROS2 applications! However as mentioned I think what zenoh is doing is a good middleground - I wonder if zenoh could be wrapped as a kube service
No sorry, i was unable to do that. If we have next time, i will set this up for sure.
the only sad thing is that we end up reverting back to the ROS1 way of doing things.
correct, once we have a server, that could be a single point failure, not distributed system anymore.
but i think that depends on use case and requirement, besides we can make it high reliability with backup server.
using headless service can allow application pods to DNS hostname, so that rosmaster and discovery server things can be resolved in runtime after deployment. as i mentioned, here is the example, it is rosmaster case, but you can see how to set and how this works.