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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
