unfortunately I most likely won’t be able to attend live. Would it be possible to record and share the meeting, because the topics are very interesting.
@mhl787156@Mukremin_Cetinkaya thank you so much for the talk !!! sorry we did not have enough time for the QA, let’s follow up some questions via this thread.
and if possible, could you share the slide deck that you used today? that would be really helpful.
@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.
Thanks for joining also. Yes definitely support robots behind any kind of NAT. VPN is automatically deployed and we have already tested in wifi and 4G/5G networks also different cloud providers.
@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!
If we use ROS 1, there will rosmaster required in the system, that is the same exact problem here. I think i can come up with some example how to describe the yaml file using headless service.
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.