coreos / discovery.etcd.io Goto Github PK

View Code? Open in Web Editor NEW

170.0 26.0 56.0 8.72 MB

etcd discovery service

Home Page: https://discovery.etcd.io

License: Apache License 2.0

Shell 5.82% Go 93.74% Dockerfile 0.44%

etcd

discovery.etcd.io's Introduction

discovery.etcd.io

If you are having issues with discovery.etcd.io please file a ticket here: https://github.com/etcd-io/discovery.etcd.io

deprecated

Old Readme

This code powers the public service at https://discovery.etcd.io. The API is documented in the etcd clustering documentation.

Configuration

The service has three configuration options, and can be configured with either runtime arguments or environment variables.

--addr / DISC_ADDR: the address to run the service on, including port.
--host / DISC_HOST: the host url to prepend to /new requests.
--etcd / DISC_ETCD: the url of the etcd endpoint backing the instance.

Docker Container

You may run the service in a docker container:

docker pull quay.io/coreos/discovery.etcd.io
docker run -d -p 80:8087 -e DISC_ETCD=http://etcd.example.com:2379 -e DISC_HOST=http://discovery.example.com quay.io/coreos/discovery.etcd.io

Development

discovery.etcd.io uses devweb for easy development. It is simple to get started:

./devweb
curl --verbose -X PUT localhost:8087/new

discovery.etcd.io's People

Contributors

Stargazers

Watchers

Forkers

randomstuffs22 rubandeventhiran mengzhuo philips th3architect nimblestratus evadne skyl visualphoenix ebergonzi bigsurge codeops meredithcorposs pelamlio yichengq wptad acumen-ctw xxyztwz zhangxin1983 jjamor materone universal-it-systems disterics tschuy zhugaoxiao domenato quantum shahtab martinyunify rusenask rickgong ericchiang lavender2020 macsummer hexfusion armstrongli vforks xieyunyue mattoglesby isabella232 johnzhaoxiaohu heichalot hanfengyizu troopert

discovery.etcd.io's Issues

Unable to generate token

I was running this:

docker pull quay.io/coreos/discovery.etcd.io
docker run -d -p 8087:8087 quay.io/coreos/discovery.etcd.io
curl --verbose -X PUT localhost:8087/new

And I'm getting:

* Hostname was NOT found in DNS cache
*   Trying ::1...
* Connected to localhost (::1) port 8087 (#0)
> PUT /new HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:8087
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Content-Type: text/plain; charset=utf-8
< Date: Mon, 23 Nov 2015 15:45:41 GMT
< Content-Length: 25
<
Unable to generate token
* Connection #0 to host localhost left intact

Any ideas?

Discovery base URL should be configurable

Right now setting up a discovery service for behind the firewall use will force an incorrect host name:

discovery.etcd.io/handlers/new.go

Line 64 in 3518a61

fmt.Fprintf(w, "https://discovery.etcd.io/"+token)

Update and improve discovery service

This service hasn't seen much attention in recent years, and it's time to fix that.

After talking with @hexfusion about etcd-io/etcd#9978, we decided on an approach that we think should let us update the service to use the v3 backend.

Add tests to ensure that improvements/refactoring don't break anything
Map out current API calls and endpoints
Add a true handler for each endpoint, rather than the current proxy
Convert the current logic to a v2 "backend"
Add a v3 backend, and allow for reading from the v2 backend first
Add a TTL to clusters to prevent data from growing unbounded over time

At that point, we will probably call the discovery service "version 3", and begin strongly encouraging people to run their own discovery services, and not rely directly on the publicly hosted instance.

devweb works...docker container /new does not

Running from devweb, works fine.
build-docker...a /new results in "unable to generate token".
docker logs: 06/Jun/2015:15:47:41 +0000] "GET /new HTTP/1.1" 400 25
setupToken returned: Couldn't setup state 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]

Calling a url with a token returns valid results.

Any pointers on the /new error running in a container?

Thanks,
Tom

http: panic serving 127.0.0.1:55530: runtime error: invalid memory address or nil pointer dereference

$ go version
go version go1.2 darwin/amd64

$ git clone https://github.com/coreos/discovery.etcd.io.git
Cloning into 'discovery.etcd.io'...
remote: Counting objects: 522, done.
remote: Compressing objects: 100% (374/374), done.
remote: Total 522 (delta 78), reused 517 (delta 73)
Receiving objects: 100% (522/522), 2.06 MiB | 237.00 KiB/s, done.
Resolving deltas: 100% (78/78), done.
Checking connectivity... done.
$ cd discovery.etcd.io
$ ./devweb
http: panic serving 127.0.0.1:55530: runtime error: invalid memory address or nil pointer dereference
goroutine 3 [running]:
net/http.func·009()
    /usr/local/go/src/pkg/net/http/server.go:1093 +0xae
runtime.panic(0x2595a0, 0x555339)
    /usr/local/go/src/pkg/runtime/panic.c:248 +0x106
github.com/coreos/etcd-discovery/handlers.setupToken(0x10, 0x7, 0x0, 0x643c50e4b71d564d)
    /Users/drnic/Projects/golang/src/github.com/coreos/discovery.etcd.io/third_party/src/github.com/coreos/etcd-discovery/handlers/new.go:35 +0x39e
github.com/coreos/etcd-discovery/handlers.NewTokenHandler(0x659680, 0xc21000acc0, 0xc210050820)
    /Users/drnic/Projects/golang/src/github.com/coreos/discovery.etcd.io/third_party/src/github.com/coreos/etcd-discovery/handlers/new.go:54 +0x26
net/http.HandlerFunc.ServeHTTP(0x323218, 0x659680, 0xc21000acc0, 0xc210050820)
    /usr/local/go/src/pkg/net/http/server.go:1220 +0x40
github.com/gorilla/mux.(*Router).ServeHTTP(0xc21001f460, 0x659680, 0xc21000acc0, 0xc210050820)
    /Users/drnic/Projects/golang/src/github.com/coreos/discovery.etcd.io/third_party/src/github.com/gorilla/mux/mux.go:98 +0x217
github.com/gorilla/handlers.loggingHandler.ServeHTTP(0x658140, 0xc210000008, 0x658400, 0xc21001f460, 0x659620, ...)
    /Users/drnic/Projects/golang/src/github.com/coreos/discovery.etcd.io/third_party/src/github.com/gorilla/handlers/handlers.go:65 +0xe6
github.com/gorilla/handlers.(*loggingHandler).ServeHTTP(0xc21000abe0, 0x659620, 0xc21006a1e0, 0xc210050820)
    /Users/drnic/Projects/golang/src/github.com/coreos/discovery.etcd.io/third_party/src/github.com/gorilla/handlers/handlers.go:1 +0xb4
net/http.(*ServeMux).ServeHTTP(0xc21001e660, 0x659620, 0xc21006a1e0, 0xc210050820)
    /usr/local/go/src/pkg/net/http/server.go:1496 +0x163
net/http.serverHandler.ServeHTTP(0xc21001fd70, 0x659620, 0xc21006a1e0, 0xc210050820)
    /usr/local/go/src/pkg/net/http/server.go:1597 +0x16e
net/http.(*conn).serve(0xc210059680)
    /usr/local/go/src/pkg/net/http/server.go:1167 +0x7b7
created by net/http.(*Server).Serve
    /usr/local/go/src/pkg/net/http/server.go:1644 +0x28b

Is there a step I'm missing do you think?

`discovery: bad discovery endpoint` Unable to GET token

I 'm getting discovery: bad discovery endpoint errors on two existing discovery endpoints.
A get request to the discovery url yields: 400 (Bad Request) Unable to GET token
However, I was able to create new discovery endpoints that work as expected.
Any known issues?

compiling error

OS: s390x/Ubuntu
Kernel: 4.10.0-30-generic
golang version: 1.9.2

Error:

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x205030b00e33000 pc=0x3acf4]

goroutine 1 [running]:
runtime.throw(0x4b8fb2, 0x2a)
/usr/local/go/src/runtime/panic.go:605 +0x98 fp=0xc4201b4980 sp=0xc4201b4968 pc=0x40a18
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:351 +0x2d8 fp=0xc4201b49c8 sp=0xc4201b4980 pc=0x59508
runtime.stkbucket(0x1, 0x100, 0xc4201b4a78, 0x1a, 0x20, 0x10000000017e3c2, 0xc4202d8aa0)
/usr/local/go/src/runtime/mprof.go:230 +0x104 fp=0xc4201b4a28 sp=0xc4201b49d0 pc=0x3acf4
runtime.mProf_Malloc(0xc42015be00, 0x100)
/usr/local/go/src/runtime/mprof.go:344 +0xa0 fp=0xc4201b4b98 sp=0xc4201b4a28 pc=0x3b480
runtime.profilealloc(0xc420440380, 0xc42015be00, 0x100)
/usr/local/go/src/runtime/malloc.go:863 +0x52 fp=0xc4201b4bb0 sp=0xc4201b4b98 pc=0x24612
runtime.mallocgc(0x100, 0x0, 0x40, 0xc4202fa200)
/usr/local/go/src/runtime/malloc.go:791 +0x4c2 fp=0xc4201b4c68 sp=0xc4201b4bb0 pc=0x23de2
runtime.growslice(0x414260, 0xc4202fa200, 0x80, 0x80, 0x81, 0xc4202fa200, 0x40, 0x80)
/usr/local/go/src/runtime/slice.go:140 +0x236 fp=0xc4201b4cc8 sp=0xc4201b4c68 pc=0x5a9b6
go/build.(*importReader).readByte(0xc4201b4dd0, 0x6e000000000b7da4)
/usr/local/go/src/go/build/read.go:44 +0x1b0 fp=0xc4201b4d48 sp=0xc4201b4cc8 pc=0x1a20c0
go/build.(*importReader).peekByte(0xc4201b4dd0, 0x100000000414260, 0x1000000006b4300)
/usr/local/go/src/go/build/read.go:90 +0x128 fp=0xc4201b4d68 sp=0xc4201b4d48 pc=0x1a2288
go/build.(*importReader).readKeyword(0xc4201b4dd0, 0x4a8534, 0x7)
/usr/local/go/src/go/build/read.go:123 +0x2e fp=0xc4201b4d90 sp=0xc4201b4d68 pc=0x1a250e
go/build.readImports(0x6b2e40, 0xc420422340, 0xc420422340, 0x0, 0xc420422340, 0x0, 0x0, 0x20, 0xc4202f67a0)
/usr/local/go/src/go/build/read.go:216 +0x76 fp=0xc4201b4e70 sp=0xc4201b4d90 pc=0x1a31c6
go/build.(*Context).matchFile(0x6f5740, 0xc4201ad000, 0x20, 0xc4201ecbc1, 0xf, 0xc4201b57e0, 0xc4203d2ee0, 0x2, 0x0, 0xda, ...)
/usr/local/go/src/go/build/build.go:1093 +0x2e6 fp=0xc4201b4f70 sp=0xc4201b4e70 pc=0x19d456
go/build.(*Context).Import(0x6f5740, 0xc4203b1a11, 0xe, 0xc4201aca80, 0x1f, 0x4, 0xc4201b6288, 0xc4201b61b0, 0xc42005fe10)
/usr/local/go/src/go/build/build.go:732 +0x9ac fp=0xc4201b5a10 sp=0xc4201b4f70 pc=0x19645c
cmd/go/internal/load.LoadImport(0xc4203b1a11, 0xe, 0xc4201aca80, 0x1f, 0xc4201da000, 0xc4201b9a98, 0xc420011e00, 0x2, 0x2, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:417 +0xae8 fp=0xc4201b5bc8 sp=0xc4201b5a10 pc=0x1fc3e8
cmd/go/internal/load.(*Package).load(0xc4201da000, 0xc4201b9a98, 0xc4203d2a80, 0x0, 0x0, 0x4)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b6430 sp=0xc4201b5bc8 pc=0x200600
cmd/go/internal/load.LoadImport(0xc4203b0ff1, 0xd, 0xc420059d50, 0x66, 0xc4201d7680, 0xc4201b9a98, 0xc42019baa0, 0x1, 0x1, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b65e8 sp=0xc4201b6430 pc=0x1fc49a
cmd/go/internal/load.(*Package).load(0xc4201d7680, 0xc4201b9a98, 0xc4203d2380, 0x0, 0x0, 0xc)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b6e50 sp=0xc4201b65e8 pc=0x200600
cmd/go/internal/load.LoadImport(0xc4201e13b1, 0x2e, 0xc42028d220, 0x43, 0xc4201d7200, 0xc4201b9a98, 0xc42022f890, 0x1, 0x1, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b7008 sp=0xc4201b6e50 pc=0x1fc49a
cmd/go/internal/load.(*Package).load(0xc4201d7200, 0xc4201b9a98, 0xc4203d2000, 0x0, 0x0, 0x4)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b7870 sp=0xc4201b7008 pc=0x200600
cmd/go/internal/load.LoadImport(0xc420193e01, 0x36, 0xc420193c80, 0x39, 0xc420407b00, 0xc4201b9a98, 0xc420122aa0, 0x3, 0x4, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b7a28 sp=0xc4201b7870 pc=0x1fc49a
cmd/go/internal/load.(*Package).load(0xc420407b00, 0xc4201b9a98, 0xc42032d500, 0x0, 0x0, 0x4)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b8290 sp=0xc4201b7a28 pc=0x200600
cmd/go/internal/load.LoadImport(0xc4201877a1, 0x2c, 0xc420193540, 0x35, 0xc420407680, 0xc4201b9a98, 0xc4204da2d0, 0x1, 0x1, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b8448 sp=0xc4201b8290 pc=0x1fc49a
cmd/go/internal/load.(*Package).load(0xc420407680, 0xc4201b9a98, 0xc42032d180, 0x0, 0x0, 0x4)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b8cb0 sp=0xc4201b8448 pc=0x200600
cmd/go/internal/load.LoadImport(0xc42001c9f1, 0x28, 0xc42001c990, 0x30, 0xc42006f680, 0xc4201b9a98, 0xc4201499b0, 0x1, 0x1, 0x1, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b8e68 sp=0xc4201b8cb0 pc=0x1fc49a
cmd/go/internal/load.(*Package).load(0xc42006f680, 0xc4201b9a98, 0xc42013aa80, 0x0, 0x0, 0xc)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1069 +0x13a0 fp=0xc4201b96d0 sp=0xc4201b8e68 pc=0x200600
cmd/go/internal/load.LoadImport(0x3fff0dff8af, 0x23, 0xc4200140a4, 0x17, 0x0, 0xc4201b9a98, 0x0, 0x0, 0x0, 0x0, ...)
/usr/local/go/src/cmd/go/internal/load/pkg.go:426 +0xb9a fp=0xc4201b9888 sp=0xc4201b96d0 pc=0x1fc49a
cmd/go/internal/load.LoadPackage(0x3fff0dff8af, 0x23, 0xc420133a98, 0x0)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1776 +0x242 fp=0xc4201b99d0 sp=0xc4201b9888 pc=0x205822
cmd/go/internal/load.PackagesAndErrors(0xc42003d900, 0x1, 0x1, 0x448a40, 0xc42003d8e0, 0xc4200e5040)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1821 +0x260 fp=0xc4201b9c00 sp=0xc4201b99d0 pc=0x2068a0
cmd/go/internal/load.PackagesForBuild(0xc420010180, 0x1, 0x1, 0x727470, 0xc420056240, 0x200001a8)
/usr/local/go/src/cmd/go/internal/load/pkg.go:1837 +0x42 fp=0xc4201b9ce8 sp=0xc4201b9c00 pc=0x206b72
cmd/go/internal/work.runBuild(0x6edca0, 0xc420010180, 0x1, 0x1)
/usr/local/go/src/cmd/go/internal/work/build.go:412 +0x78 fp=0xc4201b9e00 sp=0xc4201b9ce8 pc=0x2106a8
main.main()
/usr/local/go/src/cmd/go/main.go:133 +0x79c fp=0xc4201b9f80 sp=0xc4201b9e00 pc=0x3c005c
runtime.main()
/usr/local/go/src/runtime/proc.go:195 +0x242 fp=0xc4201b9fd8 sp=0xc4201b9f80 pc=0x422f2
runtime.goexit()
/usr/local/go/src/runtime/asm_s390x.s:947 +0x2 fp=0xc4201b9fd8 sp=0xc4201b9fd8 pc=0x71f92

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/go/src/runtime/sigqueue.go:131 +0xf6
os/signal.loop()
/usr/local/go/src/os/signal/signal_unix.go:22 +0x1e
created by os/signal.init.0
/usr/local/go/src/os/signal/signal_unix.go:28 +0x3c

This seems a run time error of golang. Any clue on this?

maybe something wrong

sudo ./devweb
Password:
setupToken returned: Couldn't setup state 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
127.0.0.1 - - [02/Jun/2015:12:04:57 +0800] "PUT /new HTTP/1.1" 400 25

curl --verbose -X PUT localhost:8087/new

Hostname was NOT found in DNS cache
Trying ::1...
Connected to localhost (::1) port 8087 (#0)

PUT /new HTTP/1.1
User-Agent: curl/7.37.1
Host: localhost:8087
Accept: /

< HTTP/1.1 400 Bad Request
< Content-Length: 25
< Content-Type: text/plain; charset=utf-8
< Date: Tue, 02 Jun 2015 04:04:58 GMT
<
Unable to generate token
Connection #0 to host localhost left intact

Unable to generate token

Im not sure if this is an issue or my lack of knowledge but I can not get my own discovery.etcd.io running. I need discovery service in private network (no access to https://discovery.etcd.io). I cloned git repository into one of my machines (ubuntu), installed go lang and run devweb executable.

When I issue curl -v -X PUT localhost:8087/new I got:

$ curl -v -X PUT localhost:8087/new
* Adding handle: conn: 0x2041b10
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x2041b10) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 8087 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8087 (#0)
> PUT /new HTTP/1.1
> User-Agent: curl/7.32.0
> Host: localhost:8087
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Content-Length: 25
< Content-Type: text/plain; charset=utf-8
< Date: Thu, 25 Sep 2014 15:12:51 GMT
<
Unable to generate token

and on devweb logs:

setupToken returned: Couldn't setup state <nil> 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
127.0.0.1 - - [25/Sep/2014:17:01:36 +0200] "PUT /new HTTP/1.1" 400 25

I tried to do some debugging and it looks like it fail CreateDir function in line 32 in file handlers/new.go

resp, err := client.CreateDir(key, 0)

Thank you in advance for help

Migrate to etcd clientv3

\cc @xiang90 @heyitsanthony

Add new port to support prometheus

We should add a new port listener (e.g. configurable but default to 8088) on which you can retrieve prometheus metrics.

add analytics ping on /new hit

We have logs from discovery.etcd.io everytime someone creates a new cluster but just for archival metrics it would be nice if we got a google analytics ping too.

use Godeps

Get rid of third_party.go and just use Godeps instead.

strip double slashes

The current code base doesn't strip double slashes. This is OK because currently discovery.etcd.io is behind a load balancer that strips those needless slashes. But, etcd 0.3+ all add double slashes when using the service such as

https://discovery.etcd.io//da837d8

secure etcd cluster

I setup a discover service with this.
But the etcd cluster for this service is brought up with https.
when I try to get the discovery link with command:

discovery start up as:

 discovery -e https://localhost:2379

try to get token as
curl --cacert /path/to/cacert --cert /path/to/cert --key /path/to/key -X PUT localhost:8087new

I got

HTTP/1.1 400 Bad Request
Unable to generate token

I use the etcd client cert and key. I can use them successfully with etcdctl.

something I missed?

simultaneous cluster initialization fails with discovery service

When starting up a three-instance cluster using a fresh discovery token, I reliably find that none or just one of the etcd daemons has succeeded in registering/starting.

This log output is from three separate machines.

-- Logs begin at Wed 2014-09-03 14:13:14 UTC, end at Thu 2014-09-04 15:49:51 UTC. --
Sep 03 22:36:05 ip-10-214-82-171.ec2.internal systemd[1]: Starting etcd...
Sep 03 22:36:05 ip-10-214-82-171.ec2.internal systemd[1]: Started etcd.
Sep 03 22:36:05 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:05.968 INFO      | The path /var/lib/etcd/log is in btrfs
Sep 03 22:36:05 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:05.969 INFO      | Set NOCOW to path /var/lib/etcd/log succeeded
Sep 03 22:36:05 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:05.969 INFO      | Discovery via https://discovery.etcd.io using prefix /722d3a7d972c80037672373c7890345c.
Sep 03 22:36:07 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:07.502 WARNING   | Discovery encountered an error: Discovery found an initialized cluster but no reachable peers are registered.
Sep 03 22:36:07 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:07.502 WARNING   | 95a44fe69f1b469fba9ce7e4ccf83b56 failed to connect discovery service[https://discovery.etcd.io/722d3a7d972c80037672373c7890345c]: Discovery 
Sep 03 22:36:07 ip-10-214-82-171.ec2.internal etcd[616]: [etcd] Sep  3 22:36:07.502 CRITICAL  | 95a44fe69f1b469fba9ce7e4ccf83b56, the new instance, must register itself to discovery service as required
Sep 03 22:36:07 ip-10-214-82-171.ec2.internal systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 03 22:36:07 ip-10-214-82-171.ec2.internal systemd[1]: Unit etcd.service entered failed state.

-- Logs begin at Wed 2014-09-03 14:13:14 UTC, end at Thu 2014-09-04 15:50:32 UTC. --
Sep 03 22:35:38 ip-10-214-79-191.ec2.internal systemd[1]: Starting etcd...
Sep 03 22:35:38 ip-10-214-79-191.ec2.internal systemd[1]: Started etcd.
Sep 03 22:35:39 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:39.465 INFO      | The path /var/lib/etcd/log is in btrfs
Sep 03 22:35:39 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:39.465 INFO      | Set NOCOW to path /var/lib/etcd/log succeeded
Sep 03 22:35:39 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:39.465 INFO      | Discovery via https://discovery.etcd.io using prefix /722d3a7d972c80037672373c7890345c.
Sep 03 22:35:40 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:40.074 WARNING   | Discovery encountered an error: Discovery found an initialized cluster but no reachable peers are registered.
Sep 03 22:35:40 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:40.074 WARNING   | 95a44fe69f1b469fba9ce7e4ccf83b56 failed to connect discovery service[https://discovery.etcd.io/722d3a7d972c80037672373c7890345c]: Discovery 
Sep 03 22:35:40 ip-10-214-79-191.ec2.internal etcd[611]: [etcd] Sep  3 22:35:40.074 CRITICAL  | 95a44fe69f1b469fba9ce7e4ccf83b56, the new instance, must register itself to discovery service as required
Sep 03 22:35:40 ip-10-214-79-191.ec2.internal systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 03 22:35:40 ip-10-214-79-191.ec2.internal systemd[1]: Unit etcd.service entered failed state.

-- Logs begin at Wed 2014-09-03 14:13:14 UTC, end at Thu 2014-09-04 15:51:13 UTC. --
Sep 03 22:36:17 ip-10-214-4-74.ec2.internal systemd[1]: Starting etcd...
Sep 03 22:36:17 ip-10-214-4-74.ec2.internal systemd[1]: Started etcd.
Sep 03 22:36:18 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:18.855 INFO      | The path /var/lib/etcd/log is in btrfs
Sep 03 22:36:18 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:18.855 INFO      | Set NOCOW to path /var/lib/etcd/log succeeded
Sep 03 22:36:18 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:18.855 INFO      | Discovery via https://discovery.etcd.io using prefix /722d3a7d972c80037672373c7890345c.
Sep 03 22:36:20 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:20.355 WARNING   | Discovery encountered an error: Discovery found an initialized cluster but no reachable peers are registered.
Sep 03 22:36:20 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:20.356 WARNING   | 95a44fe69f1b469fba9ce7e4ccf83b56 failed to connect discovery service[https://discovery.etcd.io/722d3a7d972c80037672373c7890345c]: Discovery fo
Sep 03 22:36:20 ip-10-214-4-74.ec2.internal etcd[617]: [etcd] Sep  3 22:36:20.356 CRITICAL  | 95a44fe69f1b469fba9ce7e4ccf83b56, the new instance, must register itself to discovery service as required
Sep 03 22:36:20 ip-10-214-4-74.ec2.internal systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 03 22:36:20 ip-10-214-4-74.ec2.internal systemd[1]: Unit etcd.service entered failed state.

... and is more or less identical. When I hit the discover URL I find the following.

{
  "action": "get",
  "node": {
    "key": "/_etcd/registry/722d3a7d972c80037672373c7890345c",
    "dir": true,
    "nodes": [
      {
        "key": "/_etcd/registry/722d3a7d972c80037672373c7890345c/95a44fe69f1b469fba9ce7e4ccf83b56",
        "value": "http://10.214.82.171:7001",
        "expiration": "2014-09-11T15:53:24.701739368Z",
        "ttl": 604798,
        "modifiedIndex": 95233491,
        "createdIndex": 95233491
      }
    ],
    "modifiedIndex": 94548087,
    "createdIndex": 94548087
  }
}

The one node listed is the first one in the logs above, which seems very odd.

All of these machines are coming online via an automated process (specifically, Terraform), and I'm wondering if this has to do with synchronization (or lack there of) between checking the peer list and sending registration commands.

watch doesn't return http response header first

$ curl -v http://discovery.etcd.io/9d7d774171b8b979294132884acbd2f8\?wait\=true
* Hostname was NOT found in DNS cache
*   Trying 50.18.196.189...
* Connected to discovery.etcd.io (50.18.196.189) port 80 (#0)
> GET /9d7d774171b8b979294132884acbd2f8?wait=true HTTP/1.1
> User-Agent: curl/7.39.0
> Host: discovery.etcd.io
> Accept: */*
>

reasons to support this:

etcd member returns http response header first, and discovery service will have the similar expectation
this helps client to know that the watch is happening
today's discovery client sets responseHeaderTimeout to 5s, so it needs response header to be returned fast

related: etcd-io/etcd#3126

/cc @xiang90 @jedsmith

prepend current request's host to new token url when requesting "/new"

Instead spcifying a "--host" option as the token url prefix, why not to use the current request's host.

problem with certificates of https://discovery.etcd.io going through proxy

I am setting up a clustered etcd with a discovery token in the form of https://discovery.etcd.io/blahblah.
The etcd is stuck with the following error::

2018-03-06 03:28:56.509265 E | discovery: error #0: x509: failed to load system roots and no roots provided
2018-03-06 03:28:56.509289 I | discovery: cluster status check: error connecting to https://discovery.etcd.io, retrying in 2s

The certificate is extracted using openssl s_client command shown at the end. The certificate is good for curl:

curl --cacert /etc/pki/ca-trust/source/anchors/discovery.etcd.io.crt https://discovery.etcd.io
Moved Permanently.

But the same certificate does not work for wget:

wget --ca-certificate /etc/pki/ca-trust/source/anchors/discovery.etcd.io.crt https://discovery.etcd.io
--2018-03-05 22:27:50-- https://discovery.etcd.io/
Resolving discovery.etcd.io (discovery.etcd.io)... 54.183.250.138, 52.9.105.182
Connecting to discovery.etcd.io (discovery.etcd.io)|54.183.250.138|:443... connected.
ERROR: cannot verify discovery.etcd.io's certificate, issued by ‘/C=US/ST=California/O=Zscaler Inc./OU=Zscaler Inc./CN=Zscaler Intermediate Root CA (zscaler.net)/emailAddress=[email protected]’:
unable to get issuer certificate
To connect to discovery.etcd.io insecurely, use `--no-check-certificate'.

The above certificate is added to the system bundle file /etc/pki/tls/certs/ca-bundle.crt on Oracle Linux, a variation of RedHat. That satisfies curl.

The etcd container runs on kubernetes, using a yaml file from https://kubernetes.io/docs/admin/high-availability/etcd.yaml with minor changes. All the local pathes in this yaml file are mounted exactly as in that yaml file:

  path: /etc/ssl        certs/ca-bundle.crt
  path: /usr/share/ssl
  path: /var/ssl
  path: /usr/ssl
  path: /usr/lib/ssl   
  path: /usr/local/openssl
  path: /etc/openssl  ca-bundle.crt
  path: /etc/pki/tls    certs/ca-bundle.crt

The ca bundle is accessible via two of the paths by default, the first and last in the above list. I also added the bundle file to the /etc/openssl directory to no avail.

The etcd image used is container-registry.oracle.com/kubernetes/etcd-amd64:3.0.17, supposed to be the same as the official image.

Outupt of openssl s_client -connect discovery.etcd.io:443 -verify 5 -showcerts is the following and its entity is used as the certificate:

CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=discovery.etcd.io
   i:/C=US/ST=California/O=Zscaler Inc./OU=Zscaler Inc./CN=Zscaler Intermediate Root CA (zscaler.net)/[email protected]
-----BEGIN CERTIFICATE-----
MIID8TCCAtmgAwIBAgIQAl3wbwKWzGFUEWmlSOxPoDANBgkqhkiG9w0BAQsFADCB
qTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFTATBgNVBAoTDFpz
Y2FsZXIgSW5jLjEVMBMGA1UECxMMWnNjYWxlciBJbmMuMTMwMQYDVQQDEypac2Nh
bGVyIEludGVybWVkaWF0ZSBSb290IENBICh6c2NhbGVyLm5ldCkxIjAgBgkqhkiG
9w0BCQEWE3N1cHBvcnRAenNjYWxlci5jb20wHhcNMTcxMjA4MDAwMDAwWhcNMTkw
MTA4MTIwMDAwWjAcMRowGAYDVQQDExFkaXNjb3ZlcnkuZXRjZC5pbzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ0WwyAJ0tglwqkurRPiHqx8kkSO4vmk
uA9Z4OyaYmzmORpAJZrZZ3xMS8r67YxsZkLwAEs6zy51RDtxDn64GnOhj33yct5r
UE+2fXq+YnoGx8pftWOBuW0UmESJ1hfLIds8XPr7svbx/OlQVjAWwKQdhOgxuBSz
wShDJYSrvo6ylh6MylrMUUOIIMM3o0MamnH/FkEx40/60FQuedi8OfkwayJIodD4
mMAMlxFIAq3uaZk7f3Stwo8HIe2BKoZeCnu6GcEMoHZHBJFkFpFkLExDEvnA+wWX
0asF4/x2G1s9MjMf7hNEa5Mnns7YwEs5JosA+PvmOtNZ4bi4jXic8SkCAwEAAaOB
oDCBnTAcBgNVHREEFTATghFkaXNjb3ZlcnkuZXRjZC5pbzAOBgNVHQ8BAf8EBAMC
BaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAw
QAYDVR0fBDkwNzA1oDOgMYYvaHR0cDovL2dhdGV3YXkuenNjYWxlci5uZXQvenNj
YWxlci16c2NybC0tNC5jcmwwDQYJKoZIhvcNAQELBQADggEBAHhhWrm9NiC8kNM5
VLFvPOMo67Gj2sngX+qBXgcbQ2NU5GWJ+lfYCdyiLpA5i9LLCOoOi3YGrGp06qfz
uPR3RXyacS4DpVUF2q1MANMwSe1hQmq0KLZkBpJYjjZvfnv6QlHDoecM/yUcnmXY
iujGq22xFh6HcYy4WvCZXUA0lWiiVePcAJwobilXtvyCrmPLsNpsqql1Kjo9EQ5g
mkcqjAxRutIzk9lVKG7WPT8IoJfKeZ0q1+t+CNZO/9wY1VxfzwYgzjsmIyDy66Yy
d07hM7YDRoa9+Tqhya2+uDabVGmjwUvaU8bZ4ybyp4BVPdZru7LWJG61LaMUqjNv
9jRTOsI=
-----END CERTIFICATE-----
 1 s:/C=US/ST=California/O=Zscaler Inc./OU=Zscaler Inc./CN=Zscaler Intermediate Root CA (zscaler.net)/[email protected]
   i:/C=US/ST=California/L=San Jose/O=Zscaler Inc./OU=Zscaler Inc./CN=Zscaler Root CA/[email protected]
-----BEGIN CERTIFICATE-----
MIIEBDCCAuygAwIBAgICd3wwDQYJKoZIhvcNAQELBQAwgaExCzAJBgNVBAYTAlVT
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMREwDwYDVQQHEwhTYW4gSm9zZTEVMBMGA1UE
ChMMWnNjYWxlciBJbmMuMRUwEwYDVQQLEwxac2NhbGVyIEluYy4xGDAWBgNVBAMT
D1pzY2FsZXIgUm9vdCBDQTEiMCAGCSqGSIb3DQEJARYTc3VwcG9ydEB6c2NhbGVy
LmNvbTAeFw0xNTAxMDYyMjM2MzRaFw00MjA1MjMyMjM2MzRaMIGpMQswCQYDVQQG
EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEVMBMGA1UEChMMWnNjYWxlciBJbmMu
MRUwEwYDVQQLEwxac2NhbGVyIEluYy4xMzAxBgNVBAMTKlpzY2FsZXIgSW50ZXJt
ZWRpYXRlIFJvb3QgQ0EgKHpzY2FsZXIubmV0KTEiMCAGCSqGSIb3DQEJARYTc3Vw
cG9ydEB6c2NhbGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJ0WwyAJ0tglwqkurRPiHqx8kkSO4vmkuA9Z4OyaYmzmORpAJZrZZ3xMS8r67Yxs
ZkLwAEs6zy51RDtxDn64GnOhj33yct5rUE+2fXq+YnoGx8pftWOBuW0UmESJ1hfL
Ids8XPr7svbx/OlQVjAWwKQdhOgxuBSzwShDJYSrvo6ylh6MylrMUUOIIMM3o0Ma
mnH/FkEx40/60FQuedi8OfkwayJIodD4mMAMlxFIAq3uaZk7f3Stwo8HIe2BKoZe
Cnu6GcEMoHZHBJFkFpFkLExDEvnA+wWX0asF4/x2G1s9MjMf7hNEa5Mnns7YwEs5
JosA+PvmOtNZ4bi4jXic8SkCAwEAAaM8MDowHQYDVR0OBBYEFIedbYoiBqnrqKCA
ddzKcd2UWyisMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgH+MA0GCSqGSIb3DQEB
CwUAA4IBAQAxt5rXlBIJqS4pYyoitWk1SqNNQnkH0pnMJrtnPlAPosXvRWvtEosx
pgYsSOoEKPqQ7hYxSUITc2cUBEBco0FK/2e73L0dSqeMi8hMMnSR8+YFC96n92R4
wtE+uRuY307xKkmIufaSbBNrJoo82HkZ6dGD2J6SbyzfGKQoTDNQBfvk1mYeafxW
7fvExvq6WlVnAJTeg0J5yGg4TWHU2WpgOgG1N3fqCxfAwvlD3uwUYrYgb3mNItCS
M4GYCkCPrwDV0VsLMsmYwtS8U4/jiWfd5Gf43mrkIDobb2Jf6RQpfHOs5xHJDxOj
yzkPMM6VQRmc92J+EH0+7xLErab7E7mg
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=discovery.etcd.io
issuer=/C=US/ST=California/O=Zscaler Inc./OU=Zscaler Inc./CN=Zscaler Intermediate Root CA (zscaler.net)/[email protected]
---
No client certificate CA names sent
---
SSL handshake has read 2182 bytes and written 633 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: E2971174441E002FF39B54039F14784B3724284A89190FC167BFC33DF9C9F5D0A1C49117A930CCB5B9CBDAAA81AAC996
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1520298351
    Timeout   : 300 (sec)
    Verify return code: 2 (unable to get issuer certificate)
---

Urls in Readme.md out of date

The two links in the Readme.md is obsolete:
https://github.com/coreos/etcd/tree/master/Documentation/cluster-discovery.md https://github.com/coreos/etcd/tree/master/Documentation/discovery-protocol.md

Discovery not working properly

Hi, I am starting some coreOS (alpha 435) instances in a cloud provider (within a security group) with the following cloud-config.

#cloud-config

hostname: etcd
coreos:
  fleet:
    metadata: role=etcd
  etcd:
    name: etcd
    discovery: https://discovery.etcd.io/<token>
    addr: $public_ipv4:4001
    bind-addr: 0.0.0.0
    peer-addr: $public_ipv4:7001
    cluster-active-size: 1
    snapshot: true
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
  update:
    group: alpha
    reboot-strategy: off

I know that I am using $public_ipv4 for both addr and peer-addr but this is taken care of within the security group. etcd is 0.4.6 . Each machine has a different /etc/machine-id
I use the discovery URL discovery.etc.io. The first instance seems to register fine, etcd starts and I can list my node with fleetctl. But the second machine (started within 1 minute) seems badly setup:

$ fleetctl list-machines
2014/09/22 11:27:56 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused
2014/09/22 11:27:56 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 100ms

$journalctl -u etcd.service
...
Sep 22 11:34:55 etcd etcd[1041]: [etcd] Sep 22 11:34:55.653 INFO      | The path /var/lib/etcd/log is in btrfs
Sep 22 11:34:55 etcd etcd[1041]: [etcd] Sep 22 11:34:55.653 INFO      | Set NOCOW to path /var/lib/etcd/log succeeded
Sep 22 11:34:55 etcd etcd[1041]: [etcd] Sep 22 11:34:55.654 INFO      | Discovery via https://discovery.etcd.io using prefix /<token>.
Sep 22 11:34:56 etcd etcd[1041]: [etcd] Sep 22 11:34:56.797 WARNING   | Discovery encountered an error: Discovery found an initialized cluster but no reachable peers are registered.
Sep 22 11:34:56 etcd etcd[1041]: [etcd] Sep 22 11:34:56.797 WARNING   | etcd failed to connect discovery service[https://discovery.etcd.io/<token>]: Discovery found an initialized cluster but no reachab
Sep 22 11:34:56 etcd etcd[1041]: [etcd] Sep 22 11:34:56.798 CRITICAL  | etcd, the new instance, must register itself to discovery service as required
Sep 22 11:34:56 etcd systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 22 11:34:56 etcd systemd[1]: Unit etcd.service entered failed state.

I can curl -X GET the discovery url with the token and I see only one node listed, the one that has a failed setup.

Support CORS headers for web browsers

I noticed that https://discovery.etcd.io/new doesn't respond with CORS (Cross Origin Resource Sharing) headers:

$ curl -i -w "\n" https://discovery.etcd.io/new
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Date: Thu, 02 Oct 2014 09:55:23 GMT
Content-Length: 58
Connection: keep-alive

https://discovery.etcd.io/$token

This means that JS web apps on different domains are unable to get discovery tokens from https://discovery.etcd.io/new. If browsers were able to get tokens, some interesting possibilities would pop up (I'm using DO as an example):

Get unique discovery token from https://discovery.etcd.io/new
Perform OAuth authentication against DO to get an OAuth Access Token
Create new DO droplets with the CoreOS image via their API by POSTing the cloud-config as user data. The cloud-config would include the discovery token generated in (1)

What this basically means: Setting up a CoreOS cluster from a web browser without any setup and just a few clicks. Pretty cool. My motivation for this is a browser based editor I'm working on. It generates tarball archives and sends them to dockerd for building. Being able to set up a (development) CoreOS cluster from a browser with a few clicks would be a first step towards cluster awareness in the dev environment.

DO has good CORS support which is documented here.

What is the correct procedure to connect to a self-hosted discovery.io?

Problem: I'm trying to get an etcd cluster to connect to a self-hosted discovery.io in a private network (172.17.8.106), and pointing an etcd -discovery at the token-generator fails, while pointing it to the etcd instance which the token-generator uses works.

Is it correct to directly hit the etcd instance? Or is this an etcd problem?

Replication

My discovery.io service is inside a docker container, with the 4001 and 7001 (for etcd) and 8087 (for devweb) mapped to 49153, 49154, 49155 respectively.
I am running etcd on version 0.4.3

To reproduce: Set up the discovery service in the container and get it running. Then curl for a token. This will return:

https://discovery.etc.io/685a3784af6d7ad38a2627a0d6e6220a

In another window, run

etcd -name test1 -peer-addr 172.17.8.106:7001 -addr 172.17.8.106:4001 -discovery http://172.17.8.106:49155/685a3784af6d7ad38a2627a0d6e6220a

which returns...

[etcd] Jun 13 12:25:23.556 WARNING   | Using the directory test1.etcd as the etcd curation directory because a directory was not specified.
[etcd] Jun 13 12:25:23.560 INFO      | The path test1.etcd/log is in btrfs
[etcd] Jun 13 12:25:23.563 INFO      | Set NOCOW to path test1.etcd/log succeeded
[etcd] Jun 13 12:25:23.565 INFO      | Discovery via http://172.17.8.106:49155 using prefix /685a3784af6d7ad38a2627a0d6e6220a.
[etcd] Jun 13 12:25:24.129 WARNING   | Discovery encountered an error: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
[etcd] Jun 13 12:25:24.130 WARNING   | test1 failed to connect discovery service[http://172.17.8.106:49155/685a3784af6d7ad38a2627a0d6e6220a]: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
[etcd] Jun 13 12:25:24.131 CRITICAL  | test1, the new instance, must register itself to discovery service as required

However, if I skip the discovery service and hit etcd instead...

[etcd] Jun 13 12:33:56.056 CRITICAL  | test1, the new instance, must register itself to discovery service as required
[root@core-06 etcd-v0.4.3-linux-amd64]# ./etcd -name test1 -peer-addr 172.17.8.106:7001 -addr 172.17.8.106:4001 -discovery http://172.17.8.106:49153/v2/keys/_etcd/registry/685a3784af6d7ad38a2627a0d6e6220a
[etcd] Jun 13 12:34:06.457 WARNING   | Using the directory test1.etcd as the etcd curation directory because a directory was not specified.
[etcd] Jun 13 12:34:06.460 INFO      | The path test1.etcd/log is in btrfs
[etcd] Jun 13 12:34:06.462 INFO      | Set NOCOW to path test1.etcd/log succeeded
[etcd] Jun 13 12:34:06.464 INFO      | Discovery via http://172.17.8.106:49153 using prefix _etcd/registry/685a3784af6d7ad38a2627a0d6e6220a.
[etcd] Jun 13 12:34:06.471 INFO      | Discovery _state was empty, so this machine is the initial leader.
[etcd] Jun 13 12:34:06.473 INFO      | Discovery fetched back peer list: []
[etcd] Jun 13 12:34:06.476 INFO      | test1 is starting a new cluster
[etcd] Jun 13 12:34:06.480 INFO      | etcd server [name test1, listen on :4001, advertised url http://172.17.8.106:4001]
[etcd] Jun 13 12:34:06.482 INFO      | peer server [name test1, listen on :7001, advertised url http://172.17.8.106:7001]
[etcd] Jun 13 12:34:06.484 INFO      | test1 starting in peer mode
[etcd] Jun 13 12:34:06.485 INFO      | test1: state changed from 'initialized' to 'follower'.
[etcd] Jun 13 12:34:06.486 INFO      | test1: state changed from 'follower' to 'leader'.
[etcd] Jun 13 12:34:06.486 INFO      | test1: leader changed from '' to 'test1'.

Discovery works.

Point discovery process to a remote etcd cluster?

It looks like the discovery code has etcd endpoint URLs hardcoded in it and no documented way to override them from the command line. Is this not configurable by intent, or is it something that just hasn't been called for?

400 Bad Request when trying to get started

Probably something simple I'm overlooking. But, I was unable to successfully run the two steps in the README.

This is the output of curl:

% curl --verbose -X PUT localhost:8087/new                              !6630
* About to connect() to localhost port 8087 (#0)
*   Trying ::1...
* connected
* Connected to localhost (::1) port 8087 (#0)
> PUT /new HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8z zlib/1.2.5
> Host: localhost:8087
> Accept: */*
> 
< HTTP/1.1 400 Bad Request
< Content-Length: 25
< Content-Type: text/plain; charset=utf-8
< Date: Tue, 14 Oct 2014 18:33:07 GMT
< 
Unable to generate token
* Connection #0 to host localhost left intact
* Closing connection #0

This is the output of devweb:

[master][~/Code/github/discovery.etcd.io]$ ./devweb 

setupToken returned: Couldn't setup state <nil> 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
127.0.0.1 - - [14/Oct/2014:11:33:06 -0700] "PUT /new HTTP/1.1" 400 25

CNCF should maintain the discovery.etcd.io service

Goal: A stable, maintained, and easy to operate discovery.etcd.io service with CNCF ownership and on-call.

A document outlining the rough plan is being drafted here: https://docs.google.com/document/d/1_GGoFL708S5Ii2sxrpwGlx9WVLqIvV9ZKeIH3x5fljg/edit