From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C8A53469710 for ; Fri, 20 Nov 2020 15:14:05 +0300 (MSK) Received: by mail-lf1-f54.google.com with SMTP id e139so13166568lfd.1 for ; Fri, 20 Nov 2020 04:14:05 -0800 (PST) Date: Fri, 20 Nov 2020 15:14:01 +0300 From: Cyrill Gorcunov Message-ID: <20201120121401.GE875895@grain> References: <20201119194100.840495-1-gorcunov@gmail.com> <20201119194100.840495-4-gorcunov@gmail.com> <1a8fa5cf-ad2a-26f3-3a9d-95367c014cbf@tarantool.org> <20201120113454.GB875895@grain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Tarantool-patches] [RFC 3/4] cfg: prepare symbolic evaluation of replication_synchro_quorum List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: tml , Vladislav Shpilevoy On Fri, Nov 20, 2020 at 02:56:12PM +0300, Serge Petrenko wrote: >=20 > I was thinking that we're gonna return something like max(1, min(value, 3= 1)) >=20 > 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. >=20 > > > 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 inpu= t. > > That's the good point. Another question if we should allow formulas like > > n-2, and while n <=3D 2 assume the quorum to be 1? Ie max(1, eval(n)) >=20 > Yes, that's what I was=A0 speaking about above. So that when the formula = may > be evaluated correctly (i.e. without division by zero or syntax errors) i= ts > 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 wish= es > anyway. >=20 > Anyway, this is subject of a verbal discussion. Yes, better discuss. All this formalism is done in a sake "lets provide use= rs options to make sync replication guaranteed" and this contradict the requir= ements 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. > >=20 > > You know I can pass all N's here but still this doesn't guarantee anyth= ing :( > > That's why I'm for more strict rules here: > >=20 > > - allow some symbolic names such as > > "all" -> (alias for f(x) =3D n) > > "canonical" -> (alias for f(x) =3D n/2 + 1) >=20 > 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=A0 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. >=20 >=20 > Yes, that's what I'm talking about. > Even if the cfg option from=A0 this=A0 list is 'skipped' in=A0 lua, it's > referenced > directly from box_cfg_xc(). Othervise the `box_cfg_set_...` will be called > twice. > Once=A0 from box_cfg_xc(), second time from this lua code. >=20 > To be more verbose, all the setters from dynamic_cfg_skip_at_load are cal= led > on > bootstrap. But from box_cfg_xc() in C, not from Lua. If you remove an ent= ry > from dynamic_cfg_skip_at_load, the corresponding setter will be called > twice. I'll recheck, thanks Serge!