piker icon indicating copy to clipboard operation
piker copied to clipboard

Stand alone `ahabd` service tree

Open goodboy opened this issue 2 years ago • 0 comments

As part of pikerd dev and test, we need to often stop and restart the service tree a lot to run new code in various backend layers of our stack (eg. data feeds, history mgmt, clearing, and even for UI stuff) which means we stop and start ahabd supervised containers just as often. This is generally slower and unnecessary since we aren't (as often) testing new code inside the managed containers' images.

This proposes creating a separate actor tree with ahabd as the root actor which allows for long lived container run lifetimes despite pikerd being restarted more frequently during dev.

Some arch and design ideas, and questions:

  • allows running the docker supervisor on remote hosts which is closer to the long view on how a distributed setup will look.
  • where should the tractor discovery registry sit?
    • normally pikerd holds this but we could offer a sub-reg that the ahab tree registers after pikerd startup presuming pikerd is given a static address for ahabd and always contacts it to pre-load actor addrs during startup?
    • is it more sane to just put the registry in ahabd iff it is already alive when pikerd contacts it?
  • this provides motivation for a lightweight remote-host daemon to be bootstrapped on systems where we'd like to enable tractor runtime availability without having to spawn the entire runtime from scratch after connection (eg. with rsyscall we'd be contacting sshd and doing a full runtime boostrap, vs. in that setup would already be alive and ready from the tractor layer and upwards?)
  • ahabd can eventually be generalized enough to be factored out of the code base into its own lib for use as a generic trio-controlled docker-py async supervision system.

ToDos for first draft:

  • [ ] write this list :surfer:

goodboy avatar Mar 16 '23 16:03 goodboy