"./cockroach start" logs unknown errors

[Meai1]

localhost:

1. What version of CockroachDB are you using (cockroach version)?

./cockroach version
Build Vers: go1.6
Build Tag: beta-20160330
Build Time: 2016/03/30 14:53:35

1. What operating system and processor architecture are you using?

uname -a
Linux localhost.localdomain 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 31 16:04:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

1. What flags/environment variables did you pass to cockroach start?

nothing

Please describe the issue you observed:

1. What did you do?

./cockroach start

1. What did you expect to see?

info output

1. What did you see instead?

error output:

E160409 10:22:21.320101 storage/queue.go:511 [replicate] 13 replicas failing with "0 of 1 store with an attribute matching []

[petermattis]

@Meai1 Thanks for the report. This is an "expected" error when you are running a single node cluster.

I think we need to find a way to squash this error for good in single node clusters. Otherwise we're going to be answering this same question over and over.

[bdarnell]

The question is how do we know it's a single-node cluster? Do we add a zone set step to the setup instructions so the user can tell us? Or do we just assume it's a single-node cluster until we see a second node?

I think we should do the latter. In the event that this is meant to be a multi-node cluster but things are misconfigured so the nodes aren't actually talking to each other, this once-per-ten-minutes log message is not going to be the best way to inform the admin of this fact. This message is at its most visible exactly when it's least useful, since the single-node case is the only one in which there's likely to be a terminal attached to the logs.

[JackKrupansky]

Maybe you simply have to require that the user state their intent, more clearly, in terms that a typical user would understand, and have some information messages that reinforce those expectations, so that it will be clear whether this single node is intended to be part of a cluster or a standalone node/cluster. For example, have an "expected cluster size" option. And then you can debate whether it defaults to 3 or 1. Either way, a startup information message can reinforce the expectation. Also reinforce the expectation as to whether this node is starting a new cluster or will be joining an existing cluster with a clean information message.

Or maybe the message should simply state the obvious: "There are insufficient nodes in this cluster to perform the configured level of replication (3) - either add nodes or reduce replication".

I think part of the problem is that the default zone configuration is hidden within the source code.

[petermattis]

I think it is fine to assume a single-node cluster until we see a second node. We might want to highlight the lack of replication in the admin UI for a single-node cluster.