Re: Supervisor and configuration update — how to d o it?

https://github.com/flussonic/reconfigurable_supervisor

Here is an initial test implementation of patches to supervisor that
allows to reconfigure it on fly.

I want to try the approach when the supervisor calls again
Mod:init(Args), get new (maybe modified) childspec and makes calls to
all children, telling them to update their start args.

Child decides whether to handle this update call or die (silently or not).


I'm going to test this code in our flussonic and if it goes ok, maybe
offer it as a patch to the supervisor.erl

On Mon, May 25, 2020 at 11:08 PM Michael Truog <[email protected]> wrote:
>
> On 5/25/20 11:08 AM, Max Lapshin wrote:
> > I'm afraid that I haven't got your idea.
> >
> >
> > Look, I have a live video stream. It collects video frames into big
> > chunks. There is a configuration setting that allows to change size of
> > these chunks: from 1 seconds to 10 seconds.
> >
> > This configuration must be done without any restarts.
> >
> > How do you advice to do this configuration?
> I am a fan of using process messages to change configuration, for two
> main reasons:
> 1) The configuration data stays consistent because the changes are
> controlled (i.e., the state changes go through sequential states,
> keeping the number of possible states small, making things easier to
> test and understand)
> 2) Specific errors when configuration problems occur are able to be
> handled, probably by reporting the problem to who changed the
> configuration and either avoiding or limiting the configuration change.
> A configuration error during startup should cause the startup to fail,
> to avoid the undefined runtime length pursuing erroneous operation.
>
> Assuming a gen_server process, use a call if the configuration change is
> able to return an error.  If no error is possible, e.g., if a record
> field is updated and that is all that happens, use a cast.  The
> configuration change might be slow when changing 1000s of processes, but
> the messages can be done in parallel and the benefits (everything can be
> tested in a controlled way, all the configuration states are valid, no
> inconsistent configuration data will occur, etc.) are better than
> pursuing the global data approach.
>
> Best Regards,
> Michael