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