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 ahabdiff 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.
As part of
pikerddev 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 startahabdsupervised 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
ahabdas the root actor which allows for long lived container run lifetimes despitepikerdbeing restarted more frequently during dev.Some arch and design ideas, and questions:
tractordiscovery registry sit?pikerdholds this but we could offer a sub-reg that theahabtree registers afterpikerdstartup presumingpikerdis given a static address forahabdand always contacts it to pre-load actor addrs during startup?ahabdiff it is already alive whenpikerdcontacts it?tractorruntime availability without having to spawn the entire runtime from scratch after connection (eg. withrsyscallwe'd be contactingsshdand doing a full runtime boostrap, vs. in that setup would already be alive and ready from thetractorlayer and upwards?)ahabdcan eventually be generalized enough to be factored out of the code base into its own lib for use as a generictrio-controlleddocker-pyasync supervision system.ToDos for first draft: