Etcd: Is ETCD discovery down?

[ankitforcode]

This page isn’t working
discovery.etcd.io is currently unable to handle this request.
HTTP ERROR 503

[hexfusion]

/cc @gyuho, @philips is this service still supported?

*   Trying 52.9.92.97...
* TCP_NODELAY set
* Connected to discovery.etcd.io (52.9.92.97) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=discovery.etcd.io
*  start date: Dec  8 00:00:00 2017 GMT
*  expire date: Jan  8 12:00:00 2019 GMT
*  subjectAltName: host "discovery.etcd.io" matched cert's "discovery.etcd.io"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET /new?size=3 HTTP/1.1
> Host: discovery.etcd.io
> User-Agent: curl/7.61.0
> Accept: */*
> 
< HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
< Content-Length: 0
< Connection: keep-alive
< 
* Connection #0 to host discovery.etcd.io left intact

I think this is the LB responding.

[ankitforcode]

@hexfusion I have an old production cluster that is still using the discovery endpoint and was able to use that some time back today morning. This could have been down since last few hours.

I can switch the existing cluster to use the private ip's however that could require more effort.

[hexfusion]

@ankitforcode sure I am just curious if this service is going to be supported moving forward. I know the package is not maintained https://github.com/coreos/etcd/issues/9836

We should remove from docs in that case IMO.

[ankitforcode]

@hexfusion The url is working again. 👍

[ankitforcode]

replied too early, it went down again 👎

[espala]

It's still down. It shouldn't take that long. There is no status page to follow.

could the service be over?

[hexfusion]

@espala I have pinged the folks who would know. The domain etcd.io will move to the new org soon https://github.com/coreos/etcd/issues/9965 so perhaps the community will be able to support the service directly in the future. For now I am afraid I have no transparency on the matter.

[hexfusion]

This service appears to be working as expected again. I expect further conversations will take place in the upcoming weeks regarding its future.

[ledsole]

Looks like it's down again

[strigazi]

Down again

Wed Aug 8 10:09:19 UTC 2018

[joelegasse]

discovery.etcd.io is currently in a degraded state. We are working on getting it back online, attempting to preserve what we can. As mentioned here the site has not been maintained, and will soon be deprecated.

What kind of use cases or scenarios are people running into that can't be solved without this service? Is it just being used for convenience, or are there technical obstacles that are being hit when attempting to initialize a cluster?

[philips]

The service is operational again. Please let us know if you hit more issues.

Also, we would like feedback on why you are using discovery.etcd.io vs. static configuration as we decide how to maintain or deprecate the service overtime.

[waipeng]

Hi @philips, thanks for bringing it back!

OpenStack Magnum kubernetes cluster uses discovery.etcd.io by default when spinning up new clusters.
https://docs.openstack.org/magnum/latest/user/

[canori01]

@philips we use this at Openstack Magnum to bootstrap etcd clusters. It allows us to easily stand up the clusters without knowing the ip addresses of the nodes in advance.

[hexfusion]

Discovery endpoint is still stuck in /v2 which is not supported. Perhaps efforts should be made to bring this into /v3? This way users can stand up there own "discovery cluster" and have it supported. In general, token generation/management is a workflow that could be handled in many different ways. But providing the capabilities seems to be a general asset to users and having that native to etcd API makes sense to me. Implemention of a "discovery cluster" via etcd-operator would probably make this all quite trivial.

If documented and supported I think there would be little reason to need the public service. But currently we give the user no supported alternative. Just my 2c.

ref: custom-etcd-discovery-service

[philips]

Someone porting discovery to a v3 API would be greatly appreciated. It
simply hasn't been a priority.

On Wed, Aug 15, 2018 at 5:52 AM Sam Batschelet [e-mail]
wrote:

Discovery endpoint is still stuck in /v2 which is not supported. Perhaps
efforts should be made to bring this into /v3? This way users can stand up
there own "discovery cluster" and have it supported. In general, token
generation/management is a workflow that could be handled in many different
ways. But providing the capabilities seems to be a general asset to users
and having that native to etcd API makes sense to me. Implemention of a
"discovery cluster" via etcd-operator would probably make this all quite
trivial.

If documented and supported I think there would be little reason to need
the public service. But currently we give the user no supported
alternative. Just my 2c.

ref: custom-etcd-discovery-service
https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md#custom-etcd-discovery-service

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/coreos/etcd/issues/9978#issuecomment-413188030, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACDCACk7ZeZturf77gm9OLKEuN61eWqks5uRBmngaJpZM4VschR
.

[gyuho]

@philips I tried

• https://github.com/coreos/discovery.etcd.io/pull/53
• https://github.com/coreos/discovery.etcd.io/pull/54
• https://github.com/coreos/discovery.etcd.io/pull/55

Just need someone to review and do the migration work for old v2 data :)

[hexfusion]

@philips, @gyuho I will make some effort to grease the wheels on this over the weekend as the issue seems timely, and I ran my mouth about needing it fixed :). If anyone else is interested in working on this please ping me so we are can distribute efforts.

[joelegasse]

@hexfusion I can help out, how would you like to coordinate?

[hexfusion]

Hi @joelegasse, sounds great I guess for starters we need to review the above. I have seen the folks at grpc-go use https://reviewable.io for larger stuff. I wonder if it would be useful to collab here or just make things overly complicated.

There is a lot going on with what he already did so I guess we both need to get a general grasp of the approach and review code as we go. I expect the first part to take a fair amount of time. I plan to hit this hard over the weekend. I will email you my details and we can chat over slack if that works for you.

Looking forward to it.

[xiang90]

this issue is tracked here: https://github.com/coreos/discovery.etcd.io/issues/61. closing