Heartbeat timeout means the period length that indicates heartbeat is
out of service, which is different from heartbeat interval.
So we should use '-peer-heartbeat-interval' instead of
'-peer-heartbeat-timeout' in etcd.
'-peer-heartbeat-timeout' is deprecated but still could be used.
The boot order for peers is -discovery, -peers, log data, forming
new cluster itself.
Special rules:
1. If discovery succeeds, it would find peers specified by discover URL
only.
2. Etcd would fail when meeting bad -discovery, no -peers and log data.
Add TestDiscoveryDownNoBackupPeersWithDataDir as the test.
Make sure that all of the servers exit before we return by using a
WaitGroup in each handler. This was used to help track down the issue
with the TestDiscoverySecondPeerUp test and the hung go-etcd watcher.
Use PUT /_state?prevExist=true in the protocol instead of PUT
/_state?prevValue=init. This lets people point one vanilla etcd at the
key prefix of another vanilla etcd and have it just work.
This tests a variety of failure cases for the Discovery service
including:
- Initial leader failures
- Discovery service failures
- Positive tests for discovery working flawlessly
for i in github.com/BurntSushi/toml github.com/coreos/go-etcd/etcd github.com/coreos/go-log/log github.com/gorilla/context github.com/rcrowley/go-metrics bitbucket.org/kardianos/osext github.com/coreos/go-systemd/journal github.com/coreos/raft code.google.com/p/goprotobuf/proto ; do goven -copy -rewrite $i; done
* server/cors.go renamed to http/cors.go
* all CORS code removed from Server and PeerServer
* Server and PeerServer fulfill http.Handler, now passed to http.Serve
* non-HTTP code in PeerServer.Serve moved to PeerServer.Start
* -trace flag controls whether or not to enable metrics-gathering
and the /debug/* HTTP endpoints
* -graphite-host flag controls where metrics should be sent
* timer.ae.handle metric tracks execution time of AppendEntriesRequest
This commits adds test coverage for all the error and non-error cases
described below, but only the behavior of the 403, 404 and 412 cases
are changing in this commit.
When setting a key results in a new resource, we asset an HTTP status
code of 201 (aka "Created").
When attempting to get a resource that doesn't exist, we assert an
HTTP status code of 404 (aka "Not Found").
When attempting to delete a directory without dir=true, or a non-empty
directory without recursive=true, but the request is otherwise valid,
we assert an HTTP status code of 403 (aka "Forbidden").
When a precondition (e.g. specified by prevIndex, or prevValue) is not
met, but the request is otherwise syntactically valid, we assert an
HTTP status code of 412 (aka "Precondition Failed"). However,
prevExist is handled slightly differently. If prevExist=false fails,
then this is treated like a failed precondition, so it should use
PreconditionFailed. But, if prevExist=true fails, then this is
treated like other requests that require the existence of the
resource, and uses NotFound if the resource doesn't exist.
We continue to assert an HTTP status code of 400 when the request is
syntactically invalid (e.g. when prevIndex=bad_index).
