Migration to rmw_zenoh

[luca-della-vedova]

Since rmw_zenoh was released as a binary (pending the next Jazzy sync) we should be able to migrate to it. Incidentally this will also help cutting down compilation time since we don't need to vendor / build the bridge from source anymore.
We can update nexus_network_configuration to generate the json5 config files needed for zenoh configuration.

This ticket is to discuss what the architecture would look like. One possible architecture (but I'm in no way an rmw_zenoh expert!):

One router per workcell

Each workcell would have its own zenoh router, from what I understand this is pretty much necessary to allow nodes within a workcell to communicate with each other. If there was only one global router at the system orchestrator level they would need to connect to it to discover nodes.

Workcell sessions

Each workcell node will have a workcell specific session config file where it connects to the workcell's router. We will use the domainid to namespace the workcell topics. We probably (?) don't need to set up an ACL in the workcell nodes themselves.

Workcell ACL

The workcell routers will have an ACL to make sure that only liveliness tokens / pub / sub / services that are relevant to the system orchestrator are forwarded, while the rest is blocked. An alternative would be to implement the ACL on the sessions (or both?).

System orchestrator

The system orchestrator would be fairly similar to workcells, with its router and communication to local nodes. The only difference is that it will use wildcards to allow communication with all workcells regardless of their domain id.

CC @Yadunund for feedback / ideas on whether this is a viable architecture or what a better one would look like.

[Yadunund]

Here's my recommendation which does not require any namespacing as that can get tricky.

• Each orchestrator will have unique router and session configs resp.
• For workcells and system orchestrators, take the ros_domain_id for each and assign a port for the zenohd router. Eg. 7447 + ros_domain_id.
• All workcell router configs will include the system orchestrator endpoint in the connect block. ie, each workcell router will connect to the system router.
• Session configs for each workcell and system will include the endpoint for their resp routers only in the connect block.
• Add access control settings to workcell router configs to only expose keyexpressions (liveliness tokens and ROS endpoints) related to orchestration and discovery.

[luca-della-vedova]

A caveat I came upon during implementation, if we set the ACL to default to deny here (the same way we do in the current nexus_network_configuration pipeline), topics will not be able to be discovered.
I asked in the Zenoh discord and it seems we need to add an additional rule that allows the ros2_lv ADMIN_SPACE, (as per this conversation):

key_exprs: ["@ros2_lv/**"],

[aaronchongth]

Nice! Just started venturing down this path and glad that a solution has already been found. Yeah, can confirm that setting ACL with the "@ros2_lv/**" key expression works like a charm.

this seems to be the minimal ACL config required to listen to a topic, leaving it here for reference. (edit: saw that @luca-della-vedova posted a working config too, not too sure how specific we'd like to be to differential between pub, sub, server, client, action server, action client)

I'll try out services and actions, then start prototyping the changes required to nexus_network_configuration when I can

   access_control: {
    "enabled": true,
    "default_permission": "deny",
    "rules":
    [
      {
        "id": "allow_chatter",
        "messages": [
          "put", "declare_subscriber",
          "liveliness_token", "liveliness_query", "declare_liveliness_subscriber",
        ],
        "flows":["egress", "ingress"],
        "permission": "allow",
        "key_exprs": [
          "**/chatter", "@ros2_lv/**"
        ],
      },
    ],
    "subjects":
    [
      {
        "id": "subject3",
      },
    ],
    "policies":
    [
       {
          "rules": ["allow_chatter"],
          "subjects": ["subject3"],
       },
    ]
  },

[Yadunund]

Sounds good! We can work with static files first and update nexus_network_configuration later since the existing tests rely on static config files anyways.