Global process registry

[bkolobara]

We should have a global process registry stored in the control node. The API should be similar to the node-local registry.

[Yoric]

@bkolobara Happy to take a first look at this, if it's not on any critical path, but I'll probably need some handholding, as I'm a newcomer to the codebase.

• When you speak of the node-local registry, is this crates/lunatic-registry-api?
• When you speak of the control node, is this crates/lunatic-control-axum?
• If so, does this mean expanding e.g. init_routes in lunatic-control-axum's routes.rs to expand the HTTP API? Or are you talking about a Rust-to-Rust API?

[kosticmarin]

@Yoric thanks for showing initiative!

When you speak of the node-local registry, is this crates/lunatic-registry-api?

Yes that's correct!

When you speak of the control node, is this crates/lunatic-control-axum?

Yes, the HTTP server which nodes use to register and discover each other and how they share modules.

If so, does this mean expanding e.g. init_routes in lunatic-control-axum's routes.rs to expand the HTTP API?

That's the general idea we would have HTTP API for updating the registry, for now the global registry can be stored in memory.
One thing to keep in mind the global process registry should have information about the Environment for which the process information is stored, this way we would allow unique names inside an Environment.

Just a side note:
Think #185 will land soon which changes how the control server is implemented so You might want to take a look. The HTTP API remains we just use a different framework 😄 .

[Yoric]

Some additional clarifications received through Discord

the idea is to give guests the ability to name processes. it enables you to make a logical architecture as node/process ids are not persisted between node restarts, etc. for example, your system/architecture might need a singleton process which keeps some info. other processes need to be able to get this info but they don't know the process id. the solution is to name the process and then use the name to retrieve the current node/process id.

I would create three apis: GET /api/registry/:name which returns {node_id, process_id} or 404, POST /api/registry which receives {name, node_id, process_id} and DELETE /api/registry/:name. Delete can return the previous {node_id, process_id}.

the guests update the registry using lunatic-registry-api. you need to map those three guest fns (put, get, remove) to control server APIs if lunatic is run in a distributed mode. if not, leave it like it is now (it gets info from state.registry() (rwlock on a hashmap). see how lunatic-distributed-api uses DistributedCtx (a ctx trait implemented by the process state/wasmtime store data). in distributed ctx you can access control::Client (state.distributed()). the control client is basically just a http client which sends requests to the control server (http server). just add those three methods which will send requests to the api. so to recap: we have three API end-points (lunatic-control-axum), three control client methods (lunatic-distributed), three guest fns (lunatic-registry-api). start with end-points, extend control client, extend the logic in existing guest fns