Sergey, the interface you are suggesting is internal, not external. Why
should user ever see it or care about it?
D.
On Mon, Aug 28, 2017 at 3:18 PM, Sergey Chugunov <sergey.chugu...@gmail.com>
wrote:
> Dmitriy,
>
> It was my misunderstanding, I believe that setter is not enough and we need
> a full-fledged entity.
>
> We should also be able to check if BLTs are compatible. Interface looks
> like this and use case for this functionality is described below.
>
> interface BaselineTopology {
> Collection<ClusterNode> nodes();
> boolean isCompatibleWith(BaselineTopology blt);
> }
>
> Let's consider the following scenario:
>
> 1. We have a grid with N nodes: it is up, active and has data in it. ->
> BLT #1 created.
> 2. We shutdown the grid. Then divide it into two parts: Part1_grid and
> Part2_grid.
> 3. We start and activate Part1_grid . Topology has changed -> BLT#2
> created.
> After that we shutdown that Part1_grid.
> 4. We start and activate Part2_grid. Topology also has changed -> BLT#3
> created.
> 5. Then we start Part1_grid and it's nodes try to join Part2_grid.
>
>
> If join is successful we have an undefined state of the resulting grid:
> values for the same key may (and will) differ between grid parts.
>
> So to prevent this we should keep nodes with BLT#2 from joining the grid
> with BLT#3. And we should fail nodes with an error message.
>
> Thanks,
> Sergey.
>
>
>
>
> On Wed, Aug 23, 2017 at 5:47 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
> > Sergey, I am still confused. What is the BaselineTopology interface in
> your
> > example? I thought that you agreed with me that we simply need a setter
> for
> > activation nodes, no?
> >
> > D.
> >
> > On Tue, Aug 22, 2017 at 4:47 AM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > wrote:
> >
> > > Dmitriy,
> > >
> > > As I understand you use the term "minimalActivationNodes" as a synonym
> > for
> > > BaselineTopology concept.
> > > In that case I agree with you that we can replace both "establish*"
> > methods
> > > with a simple setter method (see below in summary).
> > >
> > > Summing up the whole discussion I see the functionality as following:
> > >
> > > New concept BaselineTopology is introduced. The main features it
> enables
> > > are:
> > >
> > > 1. automatic activation of cluster;
> > >
> > > 2. easy management of cluster topology changes (planned nodes
> > > maintenance, adding new nodes etc);
> > >
> > > 3. eliminating of rebalancing traffic on short-term node failures.
> > >
> > >
> > > Use cases to create BLT:
> > >
> > > 1. user starts up new cluster of desired number of nodes and
> activates
> > > it using existing API. BLT is created with all nodes presented in
> the
> > > cluster at the moment of activation, no API is needed;
> > >
> > > 2. user prepares BLT using web-console or visor CMD tools and sets
> it
> > to
> > > the cluster. New API setter is needed:
> > > Ignite.activation().setBaselineTopology(BaselineTopology blt);
> > >
> > > 3. user provides via static configuration a list of nodes that are
> > > expected to be in the cluster.
> > > User starts nodes one by one; when all preconfigured nodes are
> started
> > > cluster is activated and BLT is created.
> > > As list of nodes may be huge it is provided via separate file to
> avoid
> > > flooding main configuration.
> > >
> > >
> > > Igniters, does this description match with your understanding of
> > > functionality? If it does I'll create a set of tickets and start
> working
> > on
> > > implementation.
> > >
> > > Thanks,
> > > Sergey.
> > >
> > >
> > > On Sat, Aug 19, 2017 at 5:41 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > I still do not see why anyone would explicitly call these 2 methods:
> > > >
> > > > *Ignite::activation::establishBaselineTopology();*
> > > > *Ignite::activation::establishBaselineTopology(BaselineTopology
> > > bltTop);*
> > > >
> > > > For example, if a web console, or some other admin process, want to
> > > > automatically set currently started nodes as the baseline topology,
> > > > shouldn't they just call a setter for minimalActivationNodes?
> > > >
> > > > D.
> > > >
> > > > On Fri, Aug 18, 2017 at 10:18 AM, Alexey Dmitriev <
> > > admitr...@gridgain.com>
> > > > wrote:
> > > >
> > > > > API is proposed in the head of the thread by Sergey, as I
> understood:
> > > > > ______________________________________________________
> > > > >
> > > > > API for BaselineTopology manipulation may look like this:
> > > > >
> > > > > *Ignite::activation::establishBaselineTopology();*
> > > > > *Ignite::activation::establishBaselineTopology(BaselineTopology
> > > > bltTop);*
> > > > >
> > > > > Both methods will establish BT and activate cluster once it is
> > > > established.
> > > > >
> > > > > The first one allows user to establish BT using current topology.
> If
> > > any
> > > > > changes happen to the topology during establishing process, user
> will
> > > be
> > > > > notified and allowed to proceed or abort the procedure.
> > > > >
> > > > > Second method allows to use some monitoring'n'management tools like
> > > > > WebConsole where user can prepare a list of nodes, using them
> create
> > a
> > > BT
> > > > > and send to the cluster a command to finally establish it.
> > > > >
> > > > > From high level BaselineTopology entity contains only collection of
> > > > nodes:
> > > > >
> > > > > *BaselineTopology {*
> > > > > * Collection<TopologyNode> nodes;*
> > > > > *}*
> > > > >
> > > > > *TopologyNode* here contains information about node - its
> consistent
> > id
> > > > and
> > > > > set of user attributes used to calculate affinity function.
> > > > > ____________________________________________
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context: http://apache-ignite-
> > > > > developers.2346864.n4.nabble.com/Cluster-auto-activation-
> > > > > design-proposal-tp20295p21066.html
> > > > > Sent from the Apache Ignite Developers mailing list archive at
> > > > Nabble.com.
> > > > >
> > > >
> > >
> >
>
