cli/start+init: Deprecate implicit initialization on absence of --join flag

[bdarnell]

There are currently two ways to initialize a cluster: Starting the first node without a --join flag, or starting all nodes with --join flags and running a separate cockroach init command. This redundancy is confusing (our docs use both methods without explaining the difference. cockroachdb/docs#2756) and it's easy to accidentally initialize a new cluster by restarting your first node with the wrong flags. (This could have catastrophic consequences in 1.1 because data from the two clusters could get mixed. We've added safeguards against this in 2.0 but it's still an easy way to break things)

I think that we should deprecate this implicit initialization mode and make the --join flag mandatory when starting a node (and therefore the init command would be mandatory too). To avoid adding too much complexity to single-node clusters, I propose a new cockroach start-single-node command to perform the start and init combination that is today implicit in the absence of a --join flag.

This would have a side benefit that we would know when the user intends to keep the cluster as a single node instead of adding more later. The start-single-node command could therefore set the replication factor to 1 to disable the "underreplicated ranges" warning (as suggested in #21429 (comment)).

In some deployment environments, it's not possible to predict the addresses or hostnames that will be assigned to other nodes until they are started. This makes it difficult to set the join flag correctly on the first node (without awkward hacks like joining the first node to itself). However, in most environments this works just fine (and in fact always passing the join flag is easier in most cases than passing it sometimes but not others).

[bdarnell]

cc @dianasaur323

[bdarnell]

The just-added cockroach demo command is similar to my proposed cockroach start-single-node command but it uses an in-memory store instead of on-disk (and does some other stuff like creating a database). We should think about whether we want two distinct commands here or if it makes sense to combine them. cc @jordanlewis

[knz]

@piyush-singh @jseldess FYI I have prepared a PR (#28495) to address this issue a while ago; however it's not merged yet and Ben suggests in #28495 (comment) that you should be the folk green lighting this work. What do you think?

[knz]

(If doc bandwidth is an issue, I could volunteer to draft the necessary changes myself.)

[jseldess]

@knz, I'm all in favor of this change and can commit to make the required docs changes. Will be a good opportunity to clean things up anyway. Let me know what else you need from me.

[piyush-singh]

Agreed that we should take this on from a PM perspective - I've seen user confused by this across several support channels and I know I was confused about this myself when I first started. I can help acceptance test and work with Jesse on any docs reviews.

[knz]

ok then I'll revive the pr

[awoods187]

Are we blocking natural growth by not allowing a path from one node to many nodes? I could easily imagine a test with one node and then adding two more nodes to the cluster to see what three-node looks like. Part of our value prop is easily scaling up the number of nodes.

I suppose you could make the argument that one node setup is for testing and no production cluster should have less than three nodes but it seems like this might add friction.

[knz]

The path would still exist - it would still be possible to grow the cluster from 1 to more, but there would be one additional step: increase the replication factor from 1 to N

[knz]

it is done