require nodecount on setup

[robertkowalski]

when setting up a node, require the nodecount from the user. when
setting up a cluster, they will probably know it, if not the ui
other interfaces can count it easily for them. this will remove
the warning for a non matching nodecount for the user, and it
is easy to implement in uis and cli clients (e.g. a wizard for
fauxton or cli client like nmo).

once clusterwide setup lands this gets obviously superfluous.

COUCHDB-2598

This closes COUCHDB-2594

[kxepal]

config:set_integer/3 is better here.

[kxepal]

I think you also need to update dev/run script.

[robertkowalski]

good point, will update it

[kxepal]

I'm neutral on this change: it's a bit strange to have a cluster that cannot scale and if it could scale then declaring cluster size is meaningless, but since we don't have any rebalancer there is no much left to be sorry about. If it solves user experience problem then fine.

However, if/when we'll have rebalancer, then such option will be instantly deprecated. Wouldn't this cause any possible confusion with such perspective?

[robertkowalski]

i think updating the config would be a part of the rebalancing process, right?

[kxepal]

Don't know, don't know. It could also use number of declared nodes in /_nodes with easy. Cannot imagine what'll happen if these two numbers will be out of sync.

[b20n]

N should not be set to the number of nodes in the cluster; those parameters are largely orthogonal.

[robertkowalski]

@banjiewen can you explain to what we would have to set N instead?

[robertkowalski]

this is the issue we are trying to fix: https://issues.apache.org/jira/browse/COUCHDB-2594

[b20n]

Bob's last comment on that ticket sounds right to me. I'd have N set to:

N = case NodeCount of
    1 -> 1;
    NC when NC >= 3 -> 3
end

Wherein bad cluster sizes (2, or < 1) are rejected (but I don't know what the project's stance on 2 node clusters is).

[kxepal]

@banjiewen @rnewson what the reasons stands behind magic number 3? Why it shouldn't be bigger? If it really shouldn't, why we allow user to configure it?

[b20n]

I'm sure larger values haven't been extensively tested, but IIUC they should work fine. N should be odd, of course.

The parameter exists to allow users/operators to manage the fault tolerance of their system, or a database within it. It should be configurable, and 3 is a very good default - it allows ~unimpeded operation of the system when one copy of the data is unavailable. If a user is willing to pay more latency, CPU, and disk space for additional fault tolerance, they can increase it.

[wohali]

@robertkowalski Where did we land with this and the associated dev/run change in apache/couchdb#331 ?