Re: Supervisor and configuration update — how to do it?

[Michael Truog]

On 5/20/20 6:39 AM, Tristan Sloughter wrote:
> You can update the childspecs with either an appup or manually using the steps an appup does of suspending the process and replacing its state with `sys` calls.
>
> Can't use that for the top level supervisor but if that crashes you go through the application start process anyway where you can pick up the new config state to pass along?
I think that if configuration is going through the start_link/init, from 
the supervisor childspec, that means the maximum restart intensity 
(MaxR) should be 0 for the top-level supervisor.  That would avoid 
relying on the supervisor's automatic restart because the childspec 
start_link arguments can not easily be changed (in an atomic way).  That 
would also mean that a single Erlang process ran by the top-level 
supervisor would be tracking the configuration state changes, making 
those changes happen in an ordered sequential way (to avoid the data 
inconsistency problems that can occur with global data used 
concurrently).  The configuration data can always be split among 
separate Erlang processes that own separate parts of the configuration, 
if that is necessary with parts of the configuration that do not have 
dependencies.

Best Regards,
Michael


>
> On Tue, May 19, 2020, at 23:36, Max Lapshin wrote:
>> Hi.
>>
>> Our flussonic has big amount of code related to smooth configuration
>> update. Almost all configuration parameters can be changed on fly: it
>> is very important, because we handle big amounts of video traffic.  It
>> is very bad to leave 20 000 people without video if you want to
>> reconfigure single channel.
>>
>>
>> We have to fight with supervisor concepts: we do not accept
>> configuration in start_link/init, because it may change later.
>>
>> Usually code is looking so:
>>
>>
>> init([Options]) ->
>>    {ok, update_options(Options, #state{})}.
>>
>> handle_info({update_options, Options}, #state{} = State) ->
>>    {noreply, update_options(Options, State)};
>>
>>
>>
>> Such approach doesn't work well with supervisor: if process is
>> restarted, it will be restarted with old Options.
>>
>> My question is: is such approach antipattern for OTP?
>> Maybe someone else has already met with it and has some ideas about
>> it, like modifying supervisor.erl to change MFA?
>>