[Tarantool-patches] [RFC 3/4] cfg: prepare symbolic evaluation of replication_synchro_quorum

[Cyrill Gorcunov]

On Fri, Nov 20, 2020 at 02:56:12PM +0300, Serge Petrenko wrote:
> 
> I was thinking that we're gonna return something like max(1, min(value, 31))
> 
> so that any evaluated number is correct. Lets better discuss this verbally
> then.

Ah, I see. Actually I don't mind to change it this way. Looks reasonable.

> 
> > > You should either check every possible value, from 1 to VCLOCK_MAX - 1,
> > > to make sure, say, that no division by zero is involved for some input.
> > That's the good point. Another question if we should allow formulas like
> > n-2, and while n <= 2 assume the quorum to be 1? Ie max(1, eval(n))
> 
> Yes, that's what I was  speaking about above. So that when the formula may
> be evaluated correctly (i.e. without division by zero or syntax errors) its
> result will automatically be correct.

+1

> I guess we shouldn't be this crazy about what is allowed in this formula and
> what's not.
> If a user has access to box.cfg{}, he may evaluate any expression he wishes
> anyway.
> 
> Anyway, this is subject of a verbal discussion.

Yes, better discuss. All this formalism is done in a sake "lets provide users
options to make sync replication guaranteed" and this contradict the requirements
with ability to run arbitrary formula :(

> > Back to the former question -- initially I assume the f gonna be linear
> > and eval in min/max will be enough. But of course this is not correct.
> > 
> > You know I can pass all N's here but still this doesn't guarantee anything :(
> > That's why I'm for more strict rules here:
> > 
> >   - allow some symbolic names such as
> >     "all" -> (alias for f(x) = n)
> >     "canonical" -> (alias for f(x) = n/2 + 1)
> 
> Sounds good to me. AFAIR others were agains it, though.

Yeah, except noone gave a good reason how manually defined formulas
are better than predefined ones. Users usually doesn't care about
config specifics they simply need a guaranteed replication to not
loose their data.

> > > You shouldn't remove replication_synchro_quorum from here.
> > > This table  lists the options which are set directly from `box_cfg` in
> > > specific order.
> > No, this table is to _skip_ evaluation on bootup. But we have to verify
> > the default value to evaluate.
> 
> 
> Yes, that's what I'm talking about.
> Even if the cfg option from  this  list is 'skipped' in  lua, it's
> referenced
> directly from box_cfg_xc(). Othervise the `box_cfg_set_...` will be called
> twice.
> Once  from box_cfg_xc(), second time from this lua code.
> 
> To be more verbose, all the setters from dynamic_cfg_skip_at_load are called
> on
> bootstrap. But from box_cfg_xc() in C, not from Lua. If you remove an entry
> from dynamic_cfg_skip_at_load, the corresponding setter will be called
> twice.

I'll recheck, thanks Serge!