Update coreos/etcd

github.com/coreos/etcd/.travis.yml

@@ -4,7 +4,7 @@ go_import_path: github.com/coreos/etcd
 sudo: false
 
 go:
-  - 1.8.1
+  - 1.8.3
   - tip
 
 notifications:
@@ -14,6 +14,8 @@ notifications:
 env:
   matrix:
    - TARGET=amd64
+   - TARGET=darwin-amd64
+   - TARGET=windows-amd64
    - TARGET=arm64
    - TARGET=arm
    - TARGET=386
@@ -24,6 +26,10 @@ matrix:
   allow_failures:
     - go: tip
   exclude:
+  - go: tip
+    env: TARGET=darwin-amd64
+  - go: tip
+    env: TARGET=windows-amd64
   - go: tip
     env: TARGET=arm
   - go: tip
@@ -35,16 +41,21 @@ matrix:
 
 addons:
   apt:
+    sources:
+    - debian-sid
     packages:
     - libpcap-dev
     - libaspell-dev
     - libhunspell-dev
+    - shellcheck
 
 before_install:
  - go get -v -u github.com/chzchzchz/goword
+ - go get -v -u github.com/coreos/license-bill-of-materials
  - go get -v -u honnef.co/go/tools/cmd/gosimple
  - go get -v -u honnef.co/go/tools/cmd/unused
  - go get -v -u honnef.co/go/tools/cmd/staticcheck
+ - ./scripts/install-marker.sh amd64
 
 # disable godep restore override
 install:
@@ -56,6 +67,12 @@ script:
       amd64)
         GOARCH=amd64 ./test
         ;;
+      darwin-amd64)
+        GO_BUILD_FLAGS="-a -v"  GOPATH="" GOOS=darwin GOARCH=amd64 ./build
+        ;;
+      windows-amd64)
+        GO_BUILD_FLAGS="-a -v"  GOPATH="" GOOS=windows GOARCH=amd64 ./build
+        ;;
       386)
         GOARCH=386 PASSES="build unit" ./test
         ;;

github.com/coreos/etcd/CODE_OF_CONDUCT.md

@@ -0,0 +1,63 @@
+## CoreOS Community Code of Conduct
+
+### Contributor Code of Conduct
+
+As contributors and maintainers of this project, and in the interest of
+fostering an open and welcoming community, we pledge to respect all people who
+contribute through reporting issues, posting feature requests, updating
+documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free
+experience for everyone, regardless of level of experience, gender, gender
+identity and expression, sexual orientation, disability, personal appearance,
+body size, race, ethnicity, age, religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery
+* Personal attacks
+* Trolling or insulting/derogatory comments
+* Public or private harassment
+* Publishing others' private information, such as physical or electronic addresses, without explicit permission
+* Other unethical or unprofessional conduct.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct. By adopting this Code of Conduct,
+project maintainers commit themselves to fairly and consistently applying these
+principles to every aspect of managing this project. Project maintainers who do
+not follow or enforce the Code of Conduct may be permanently removed from the
+project team.
+
+This code of conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting a project maintainer, Brandon Philips
+<brandon.philips@coreos.com>, and/or Meghan Schofield
+<meghan.schofield@coreos.com>.
+
+This Code of Conduct is adapted from the Contributor Covenant
+(http://contributor-covenant.org), version 1.2.0, available at
+http://contributor-covenant.org/version/1/2/0/
+
+### CoreOS Events Code of Conduct
+
+CoreOS events are working conferences intended for professional networking and
+collaboration in the CoreOS community. Attendees are expected to behave
+according to professional standards and in accordance with their employer’s
+policies on appropriate workplace behavior.
+
+While at CoreOS events or related social networking opportunities, attendees
+should not engage in discriminatory or offensive speech or actions including
+but not limited to gender, sexuality, race, age, disability, or religion.
+Speakers should be especially aware of these concerns.
+
+CoreOS does not condone any statements by speakers contrary to these standards.
+CoreOS reserves the right to deny entrance and/or eject from an event (without
+refund) any individual found to be engaging in discriminatory or offensive
+speech or actions.
+
+Please bring any concerns to the immediate attention of designated on-site
+staff, Brandon Philips <brandon.philips@coreos.com>, and/or Meghan Schofield
+<meghan.schofield@coreos.com>.

github.com/coreos/etcd/CONTRIBUTING.md

@@ -5,7 +5,7 @@ etcd is Apache 2.0 licensed and accepts contributions via GitHub pull requests.
 # Email and chat
 
 - Email: [etcd-dev](https://groups.google.com/forum/?hl=en#!forum/etcd-dev)
-- IRC: #[coreos](irc://irc.freenode.org:6667/#coreos) IRC channel on freenode.org
+- IRC: #[etcd](irc://irc.freenode.org:6667/#etcd) IRC channel on freenode.org
 
 ## Getting started
 

github.com/coreos/etcd/Dockerfile-release.arm64

@@ -0,0 +1,11 @@
+FROM aarch64/ubuntu:16.04
+
+ADD etcd /usr/local/bin/
+ADD etcdctl /usr/local/bin/
+ADD var/etcd /var/etcd
+ADD var/lib/etcd /var/lib/etcd
+
+EXPOSE 2379 2380
+
+# Define default command.
+CMD ["/usr/local/bin/etcd"]

github.com/coreos/etcd/Dockerfile-release.ppc64le

@@ -2,8 +2,8 @@ FROM ppc64le/ubuntu:16.04
 
 ADD etcd /usr/local/bin/
 ADD etcdctl /usr/local/bin/
-RUN mkdir -p /var/etcd/
-RUN mkdir -p /var/lib/etcd/
+ADD var/etcd /var/etcd
+ADD var/lib/etcd /var/lib/etcd
 
 EXPOSE 2379 2380
 

github.com/coreos/etcd/Documentation/dev-guide/api_concurrency_reference_v3.md

@@ -6,7 +6,7 @@ This is a generated documentation. Please read the proto files for more.
 
 ##### service `Lock` (etcdserver/api/v3lock/v3lockpb/v3lock.proto)
 
-for grpc-gateway The lock service exposes client-side locking facilities as a gRPC interface.
+The lock service exposes client-side locking facilities as a gRPC interface.
 
 | Method | Request Type | Response Type | Description |
 | ------ | ------------ | ------------- | ----------- |
@@ -51,7 +51,7 @@ for grpc-gateway The lock service exposes client-side locking facilities as a gR
 
 ##### service `Election` (etcdserver/api/v3election/v3electionpb/v3election.proto)
 
-for grpc-gateway The election service exposes client-side election facilities as a gRPC interface.
+The election service exposes client-side election facilities as a gRPC interface.
 
 | Method | Request Type | Response Type | Description |
 | ------ | ------------ | ------------- | ----------- |

github.com/coreos/etcd/Documentation/dev-guide/api_grpc_gateway.md

@@ -6,9 +6,11 @@ etcd v3 uses [gRPC][grpc] for its messaging protocol. The etcd project includes
 
 ## Using grpc-gateway
 
-The gateway accepts a [JSON mapping][json-mapping] for etcd's [protocol buffer][api-ref] message definitions. Note that `key` and `value` fields are defined as byte arrays and therefore must be base64 encoded in JSON.
+The gateway accepts a [JSON mapping][json-mapping] for etcd's [protocol buffer][api-ref] message definitions. Note that `key` and `value` fields are defined as byte arrays and therefore must be base64 encoded in JSON. The following examples use `curl`, but any HTTP/JSON client should work all the same.
 
-Use `curl` to put and get a key:
+### Put and get keys
+
+Use the `v3alpha/kv/range` and `v3alpha/kv/put` services to read and write keys:
 
 ```bash
 <<COMMENT
@@ -24,9 +26,16 @@ curl -L http://localhost:2379/v3alpha/kv/put \
 curl -L http://localhost:2379/v3alpha/kv/range \
 	-X POST -d '{"key": "Zm9v"}'
 # {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}
+
+# get all keys prefixed with "foo"
+curl -L http://localhost:2379/v3alpha/kv/range \
+	-X POST -d '{"key": "Zm9v", "range_end": "Zm9w"}'
+# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"3"},"kvs":[{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}],"count":"1"}
 ```
 
-Use `curl` to watch a key:
+### Watch keys
+
+Use the `v3alpha/watch` service to watch keys:
 
 ```bash
 curl http://localhost:2379/v3alpha/watch \
@@ -38,6 +47,60 @@ curl -L http://localhost:2379/v3alpha/kv/put \
 # {"result":{"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"2","raft_term":"2"},"events":[{"kv":{"key":"Zm9v","create_revision":"2","mod_revision":"2","version":"1","value":"YmFy"}}]}}
 ```
 
+### Transactions
+
+Issue a transaction with `v3alpha/kv/txn`:
+
+```bash
+curl -L http://localhost:2379/v3alpha/kv/txn \
+	-X POST \
+	-d '{"compare":[{"target":"CREATE","key":"Zm9v","createRevision":"2"}],"success":[{"requestPut":{"key":"Zm9v","value":"YmFy"}}]}'
+# {"header":{"cluster_id":"12585971608760269493","member_id":"13847567121247652255","revision":"3","raft_term":"2"},"succeeded":true,"responses":[{"response_put":{"header":{"revision":"3"}}}]}
+```
+
+### Authentication
+
+Set up authentication with the `v3alpha/auth` service:
+
+```bash
+# create root user
+curl -L http://localhost:2379/v3alpha/auth/user/add \
+	-X POST -d '{"name": "root", "password": "pass"}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}
+
+# create root role
+curl -L http://localhost:2379/v3alpha/auth/role/add \
+	-X POST -d '{"name": "root"}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}
+
+# grant root role
+curl -L http://localhost:2379/v3alpha/auth/user/grant \
+	-X POST -d '{"user": "root", "role": "root"}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}
+
+# enable auth
+curl -L http://localhost:2379/v3alpha/auth/enable -X POST -d '{}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"}}
+```
+
+Authenticate with etcd for an authentication token using `v3alpha/auth/authenticate`:
+
+```bash
+# get the auth token for the root user
+curl -L http://localhost:2379/v3alpha/auth/authenticate \
+	-X POST -d '{"name": "root", "password": "pass"}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"1","raft_term":"2"},"token":"sssvIpwfnLAcWAQH.9"}
+```
+
+Set the `Authorization` header to the authentication token to fetch a key using authentication credentials:
+
+```bash
+curl -L http://localhost:2379/v3alpha/kv/put \
+	-H 'Authorization : sssvIpwfnLAcWAQH.9' \
+	-X POST -d '{"key": "Zm9v", "value": "YmFy"}'
+# {"header":{"cluster_id":"14841639068965178418","member_id":"10276657743932975437","revision":"2","raft_term":"2"}}
+```
+
 ## Swagger
 
 Generated [Swagger][swagger] API definitions can be found at [rpc.swagger.json][swagger-doc].

github.com/coreos/etcd/Documentation/dev-guide/api_reference_v3.md

@@ -40,8 +40,6 @@ This is a generated documentation. Please read the proto files for more.
 
 ##### service `KV` (etcdserver/etcdserverpb/rpc.proto)
 
-for grpc-gateway
-
 | Method | Request Type | Response Type | Description |
 | ------ | ------------ | ------------- | ----------- |
 | Range | RangeRequest | RangeResponse | Range gets the keys in the range from the key-value store. |
@@ -72,6 +70,7 @@ for grpc-gateway
 | Defragment | DefragmentRequest | DefragmentResponse | Defragment defragments a member's backend database to recover storage space. |
 | Hash | HashRequest | HashResponse | Hash returns the hash of the local KV state for consistency checking purpose. This is designed for testing; do not use this in production when there are ongoing transactions. |
 | Snapshot | SnapshotRequest | SnapshotResponse | Snapshot sends a snapshot of the entire backend from a member over a stream to a client. |
+| MoveLeader | MoveLeaderRequest | MoveLeaderResponse | MoveLeader requests current leader node to transfer its leadership to transferee. |
 
 
 
@@ -94,8 +93,6 @@ for grpc-gateway
 
 ##### message `AlarmRequest` (etcdserver/etcdserverpb/rpc.proto)
 
-default, used to query if any alarm is active space quota is exhausted
-
 | Field | Description | Type |
 | ----- | ----------- | ---- |
 | action | action is the kind of alarm request to issue. The action may GET alarm statuses, ACTIVATE an alarm, or DEACTIVATE a raised alarm. | AlarmAction |
@@ -405,6 +402,7 @@ CompactionRequest compacts the key-value store up to a given revision. All super
 | create_revision | create_revision is the creation revision of the given key | int64 |
 | mod_revision | mod_revision is the last modified revision of the given key. | int64 |
 | value | value is the value of the given key, in bytes. | bytes |
+| range_end | range_end compares the given target to all keys in the range [key, range_end). See RangeRequest for more details on key ranges. | bytes |
 
 
 
@@ -611,6 +609,22 @@ Empty field.
 
 
 
+##### message `MoveLeaderRequest` (etcdserver/etcdserverpb/rpc.proto)
+
+| Field | Description | Type |
+| ----- | ----------- | ---- |
+| targetID | targetID is the node ID for the new leader. | uint64 |
+
+
+
+##### message `MoveLeaderResponse` (etcdserver/etcdserverpb/rpc.proto)
+
+| Field | Description | Type |
+| ----- | ----------- | ---- |
+| header |  | ResponseHeader |
+
+
+
 ##### message `PutRequest` (etcdserver/etcdserverpb/rpc.proto)
 
 | Field | Description | Type |
@@ -637,7 +651,7 @@ Empty field.
 
 | Field | Description | Type |
 | ----- | ----------- | ---- |
-| key | default, no sorting lowest target value first highest target value first key is the first key for the range. If range_end is not given, the request only looks up key. | bytes |
+| key | key is the first key for the range. If range_end is not given, the request only looks up key. | bytes |
 | range_end | range_end is the upper bound on the requested range [key, range_end). If range_end is '\0', the range is all keys >= key. If range_end is key plus one (e.g., "aa"+1 == "ab", "a\xff"+1 == "b"), then the range request gets all keys prefixed with key. If both key and range_end are '\0', then the range request returns all keys. | bytes |
 | limit | limit is a limit on the number of keys returned for the request. When limit is set to 0, it is treated as no limit. | int64 |
 | revision | revision is the point-in-time of the key-value store to use for the range. If revision is less or equal to zero, the range is over the newest key-value store. If the revision has been compacted, ErrCompacted is returned as a response. | int64 |
@@ -672,6 +686,7 @@ Empty field.
 | request_range |  | RangeRequest |
 | request_put |  | PutRequest |
 | request_delete_range |  | DeleteRangeRequest |
+| request_txn |  | TxnRequest |
 
 
 
@@ -694,6 +709,7 @@ Empty field.
 | response_range |  | RangeResponse |
 | response_put |  | PutResponse |
 | response_delete_range |  | DeleteRangeResponse |
+| response_txn |  | TxnResponse |
 
 
 
@@ -770,7 +786,7 @@ From google paxosdb paper: Our implementation hinges around a powerful primitive
 | range_end | range_end is the end of the range [key, range_end) to watch. If range_end is not given, only the key argument is watched. If range_end is equal to '\0', all keys greater than or equal to the key argument are watched. If the range_end is one bit larger than the given key, then all keys with the prefix (the given key) will be watched. | bytes |
 | start_revision | start_revision is an optional revision to watch from (inclusive). No start_revision is "now". | int64 |
 | progress_notify | progress_notify is set so that the etcd server will periodically send a WatchResponse with no events to the new watcher if there are no recent events. It is useful when clients wish to recover a disconnected watcher starting from a recent known revision. The etcd server may decide how often it will send notifications based on current load. | bool |
-| filters | filter out put event. filter out delete event. filters filter the events at server side before it sends back to the watcher. | (slice of) FilterType |
+| filters | filters filter the events at server side before it sends back to the watcher. | (slice of) FilterType |
 | prev_kv | If prev_kv is set, created watcher gets the previous KV before the event happens. If the previous KV is already compacted, nothing will be returned. | bool |
 
 
@@ -794,6 +810,7 @@ From google paxosdb paper: Our implementation hinges around a powerful primitive
 | created | created is set to true if the response is for a create watch request. The client should record the watch_id and expect to receive events for the created watcher from the same stream. All events sent to the created watcher will attach with the same watch_id. | bool |
 | canceled | canceled is set to true if the response is for a cancel watch request. No further events will be sent to the canceled watcher. | bool |
 | compact_revision | compact_revision is set to the minimum index if a watcher tries to watch at a compacted index.  This happens when creating a watcher at a compacted revision or the watcher cannot catch up with the progress of the key-value store.  The client should treat the watcher as canceled and should not try to create any watcher with the same start_revision again. | int64 |
+| cancel_reason | cancel_reason indicates the reason for canceling the watcher. | string |
 | events |  | (slice of) mvccpb.Event |