Godeps should allow me to do
godep restore
godep save -r ./...
But that doesn't work. Try it.
This requires update to the following packages:
github.com/prometheus/client_golang/
github.com/prometheus/procfs
github.com/matttproud/golang_protobuf_extensions/
There were 2 major problems.
1. godeps have code.google.com/p/goprotobuf but that repo doesn't exist
2. prometheus/client_golang/_vendor moved to other packages and godep
(with -r) can't handle it.
At the end of this we should be able to use godeps again without tons of
black magic. uggh. what a pain in the ass.
The black magic to actually get godeps back in shape was:
```bash
# remove code.google.com/p/goprotobuf (doesn't exist)
# remove all _vendor lines from prometheus (we still have other
# prometheus lines so restore still works)
vi Godeps/Godeps.json
# remove all the crazy vendoring crud because godep doesn't handle it
# correctly
find . -name \*.go | xargs sed -i
's|github.com/coreos/etcd/Godeps/_workspace/src/||'
# ok now, restore as best we can (everything except it wines about
# goprotobuf
godep restore
# now update the packages which were using the old (dead) goprotobuf
go get -u github.com/prometheus/client_golang/
go get -u github.com/matttproud/golang_protobuf_extensions/
# update prometheus procfs because prometheus/client_golang/ has a
# dependancy on this update
go get -u github.com/prometheus/procfs
# get rid of Godeps directory entirely
git rm -rf Godeps
# ok, now, rewrite the Godeps directory and redo the path rewrites
godep save -r ./...
# now put Godeps back into git
git add Godeps/
# commit the new code
git commit -aA
# And now, you can use godeps!
godep restore
godep save -r ./...
git diff
# nothing!!
```
Cluster version is the min major.minor of all members in
the etcd cluster. Cluster version is set to the min version
that a etcd member is compatible with when first bootstrapp.
During a rolling upgrades, the cluster version will be updated
automatically.
For example:
```
Cluster [a:1, b:1 ,c:1] -> clusterVersion 1
update a -> 2, b -> 2
after a detection
Cluster [a:2, b:2 ,c:1] -> clusterVersion 1, since c is still 1
update c -> 2
after a detection
Cluster [a:2, b:2 ,c:2] -> clusterVersion 2
```
The API/raft component can utilize clusterVersion to determine if
it can accept a client request or a raft RPC.
We choose polling rather than pushing since we want to use the same
logic for cluster version detection and (TODO) cluster version checking.
Before a member actually joins a etcd cluster, it should check the version
of the cluster. Push does not work since the other members cannot push
version info to it before it actually joins. Moreover, we do not want our
raft RPC system (which is doing the heartbeat pushing) to coordinate cluster version.
stub out security
further wip
Last stub before CRUD for roles
Complete role merging
start tests
add Godep for golang.org/x/crypto/bcrypt
first round of comments
add tests, remove root addition (will be added back as part of creation)
Add security checks for /v2/machines and /v2/keys
Allow non-root to determine if security is enabled, get machine list.
Responding to comments, remove multiple verbs (like /v2/security/user/foo/password)
add some prefixes to the logging
