>That would just move 3 components to another level but they are
>still needed: scanning existing service directories, diffing between
>desired and current state and applying - so creating or removing
>directories.
So, diffing between desired and current state, and applying the
modifications are components of a *service manager*, not a supervision
suite, and it is important to maintain the distinction in order to
avoid scope creep in s6.
Even when a service is *not* instanced, these components are somewhat
needed; it's just not noticed because their implementation over a
single supervised service is trivial. But it is important to remember
that the job of a supervision suite is to maintain the service in its
current state (up or down), *not* to manage the wanted state or apply
it. (Of course, it does provide tools to perform state transitions
for longruns, but it comes with no policy on when to call these tools.)
The components you want definitely have their place in s6-rc; but in
the meantime, they can also be scripted on top of regular s6 if you
have a good modelization for implementing instances, which I will add
in the near future.
>I see there a problem with multiple dynamic services. I'm not sure
>about concurrency behaviour of updating processes in the service
>directory. Maybe Laurent can explain problems in that area, if they
>exist.
s6 manages processes and every supervised process needs its own
service directory. There will be as many service directories as
they are instances. (Some components of a template service directory
can of course be reused.) So there's no concurrency issue; however,
the instance management tool I'm thinking of could adopt various
updating methods depending on what you want. Best effort? Clean
shutdown, service replacement, then firing up of the new service's
instances? Rolling upgrade across the instances? These policies all
have their uses.
>I'm not sure how complex the supervision itself is - however I would
>love to solve the problem without doing supervision on my own. I
>thought about your approach as well but it really depends how resilient
>an update process is.
It will definitely be resilient, but there are several ways to
implement
it, see above.
--
Laurent
Received on Thu Aug 18 2022 - 18:36:24 CEST