Hm... Can we also ask user to optionally provide a predicate which will
receive a collection of nodes started so far and return true if the
activation should happen? Will it be useful?
On Wed, Aug 30, 2017 at 6:28 PM, Sergey Chugunov <sergey.chugu...@gmail.com>
wrote:
> Nick,
>
> As I summed up in this thread above, calling setter for initial activation
> nodes is not the only option:
>
> 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().setInitialActivationNodes(Collection<ClusterNode>
> nodes);
>
> 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.
>
> So the option you proposed is already in the list.
>
> As for idea of activating cluster based only on number of nodes may be
> risky.
> E.g. if user starts up with data stored on disk and unexpected node joins
> the topology.
> Cluster will get activated with N-1 nodes where all the data is presented
> and one node completely empty. Data loss may happen in such scenario.
>
> Thanks,
> Sergey.
>
>
> On Wed, Aug 30, 2017 at 4:23 PM, Nick Pordash <nickpord...@gmail.com>
> wrote:
>
> > How is a user expected to produce a collection of ClusterNode prior to
> all
> > of the expected nodes joining? Users don't create instances of this, so
> as
> > far as I can tell it would have to be retrieved from IgniteCluster.
> > However, would doing that and calling the proposed method be really any
> > different than calling Ignite.activate and using the current set of
> server
> > nodes as that collection?
> >
> > From a user's perspective is it really necessary that specific nodes need
> > to be identified vs saying that they expect N server nodes to be in the
> > cluster for auto activation?
> >
> > -Nick
> >
> > On Wed, Aug 30, 2017, 1:23 AM Sergey Chugunov <sergey.chugu...@gmail.com
> >
> > wrote:
> >
> > > Dmitriy,
> > >
> > > Now I see your point and I think you're right.
> > >
> > > We can give end-user a simple setter like
> > > Ignite::activation::setInitialActivationNodes(Collection<ClusterNode>
> > > nodes) to provide collection of nodes that grid must reach to activate
> > > automatically.
> > >
> > > And then using the collection we'll create BaselineTopology abstraction
> > > internally.
> > >
> > > As a result user won't be exposed to our internal abstractions and will
> > > work with intuitive concept of collection of nodes.
> > >
> > > Thanks,
> > > Sergey.
> > >
> > >
> > > On Mon, Aug 28, 2017 at 4:39 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
