Yimo/feat/hosted - #3692
Conversation
github-actions
Bot
added
the
first-time-contributor
There was a problem hiding this comment.
we decided against multi language docs for now (since it adds maitenance burden and translation tools are so good)
There was a problem hiding this comment.
I'll keep that in mind for next time. This PR isn't built for merge so the Chinese documentation was just there to help me think things through in Chinese.I will make sure this doesn't happen again.
|
|
||
| The system has three related but separate concerns. | ||
|
|
||
| ### Discovery plane |
There was a problem hiding this comment.
keep in mind, next to RPC, zenoh also offers distributed key/value store, but this is risky/complex so I think rpc for initial implementation is a responsible choice
There was a problem hiding this comment.
Yes! I noticed that some of the transports in the dimos are implemented using Zenoh as well.
|
|
||
| This means the application can continue moving data if the controller exits | ||
| after startup, although the MVP may keep it alive to aggregate status and | ||
| coordinate shutdown. |
There was a problem hiding this comment.
I think keepalive packets will be neccessary between coordinator and Host service(s)
if someone runs kill -9 on a laptop - remote system should notice that owning blueprint is down, and shutdown it's modules
There was a problem hiding this comment.
Got it. I'll add that in just a bit
| - Host presence disappears when its Zenoh liveliness token is lost; | ||
| - a descriptor is fetched from the live Host rather than trusted from a stale | ||
| retained value; | ||
| - discovery works through routers and gossip, not only local multicast; |
There was a problem hiding this comment.
start from here (about to get merged) makes zenoh default across dimos
| | `protocol_version`, `plan_schema_version` | Control and deployment-plan compatibility. | | ||
| | `dimos_version`, `application_revision` | Runtime and code compatibility. | | ||
| | `active_runs`, `leases` | Current occupancy and pending reservations. | | ||
| | `health`, `last_error` | Whether the Host can accept work and why not. | |
There was a problem hiding this comment.
great, later we can add even system metrics etc
| MarkerDetectionStreamModule.blueprint( | ||
| marker_length_m=0.1, | ||
| camera_info=GO2Connection.camera_info_static, | ||
| ).placement(tags={"gpu"}), |
There was a problem hiding this comment.
.placement is a weird word, maybe .remote ?
There was a problem hiding this comment.
That makes a lot of sense. The reason I used "placement" is because local execution can also serve as a placement location. But "remote" is definitely clearer semantically, so I'll change it to "remote".
| | Cross-Host stream using shared memory | Rejected. | | ||
| | Other machine-local transports | Supported only when both endpoints are on the same Host. | | ||
|
|
||
| Keeping explicit shared memory for local image or point-cloud paths avoids a |
There was a problem hiding this comment.
yeah now that we merge zenoh #3617 shm will be used automatically between local modules, so all blueprints will just be on zenoh and you won't have these issues
|
|
||
| # Select one G1 Host and one GPU Host; navigation remains local. | ||
| multi_host_g1 = autoconnect( | ||
| unitree_g1.blueprint().placement(tags={"g1"}), |
There was a problem hiding this comment.
nitpick but dont like the word placement. maybe .hosted()
3 participants
This PR introduces the basic API design for hosted support. It is an initial implementation intended to establish a foundation and is open for public discussion and further iteration. @spomichter @leshy