From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com
 [209.85.167.67])
 (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 63387469710
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 25 Nov 2020 15:19:10 +0300 (MSK)
Received: by mail-lf1-f67.google.com with SMTP id u18so2818497lfd.9
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 25 Nov 2020 04:19:10 -0800 (PST)
Date: Wed, 25 Nov 2020 15:19:07 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20201125121907.GO875895@grain>
References: <20201124152405.1174898-1-gorcunov@gmail.com>
 <20201124152405.1174898-3-gorcunov@gmail.com>
 <f5e82316-0a58-09f8-17be-3a062a4780d7@tarantool.org>
 <20201125115538.GM875895@grain>
 <fd8dc7a2-ab96-b67d-a0e6-6828eb05a7b5@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fd8dc7a2-ab96-b67d-a0e6-6828eb05a7b5@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v2 2/3] cfg: support symbolic
 evaluation of replication_synchro_quorum
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Serge Petrenko <sergepetrenko@tarantool.org>
Cc: tml <tarantool-patches@dev.tarantool.org>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>

On Wed, Nov 25, 2020 at 03:10:48PM +0300, Serge Petrenko wrote:
> 
> > > > +box_renew_replication_synchro_quorum(void)
> > > What do you think of `box_update_replication_synchro_quorum`?
> > I don't mind with any name, so I'llupdate it to match.
> > 
> > You know the most thing which bothers me most is the fact
> > that we're calling box function from a deep code chain of
> > replication engine. replica_set/clear helpers are bound to
> > replication internals and ideally should know nothing about
> > box configuration that's why I thought of some kind of
> > notification hooks or triggers.
> > 
> > Say replicaset allocates a trigger on init and allow any code
> > to be notified with stage changes. In our case the stage is replica
> > id set or clear. Thus box could setup a trigger into replicaset
> > and we simply run the trigger. For me this would look a way
> > more natural but I'm not sure, because this will require to
> > introduce "stages" and instead of a single call to box_ we
> > will have a way more bigger patch with unclear picture...
> > Simply dunno.
> 
> 
> I see. I'm not sure we need to implement this.
> 
> IMO it looks ok now. Let's wait for Vladislav's opinion.

Sure, I'm fine with leaving it as a direct call for now.