proposals: add "etcd" as "Incubating" CNCF project #143
Conversation
|
/cc @caniszczyk |
caniszczyk
changed the title
proposals/etcd.adoc
Outdated
|
|
||
| *Description*: | ||
|
|
||
| etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory (although etcd still writes to disk for durabilities) and mainly used as a separate coordination service for other distributed systems like Kubernetes. Typical etcd cluster is distributed over 3 to 5 nodes, for high availability, while it prioritizes consistency and partition tolerance. Which means, it provides on logical cluster view of many physical servers. So long as majority of cluster is up, etcd continues to work, even under machine failures. This redundancy provides fault tolerance. |
There was a problem hiding this comment.
nit: durability. Also, wrapping lines around 80-120 chars makes it easier to comment.
There was a problem hiding this comment.
nits:
A typical etcd cluster...
a majority.
proposals/etcd.adoc
Outdated
|
|
||
| etcd is a consistent distributed key-value store, designed to hold small amounts of data that can fit entirely in memory (although etcd still writes to disk for durabilities) and mainly used as a separate coordination service for other distributed systems like Kubernetes. Typical etcd cluster is distributed over 3 to 5 nodes, for high availability, while it prioritizes consistency and partition tolerance. Which means, it provides on logical cluster view of many physical servers. So long as majority of cluster is up, etcd continues to work, even under machine failures. This redundancy provides fault tolerance. | ||
|
|
||
| etcd server implements Raft consensus algorithm for data replication. Raft is a leader-based protocol. Data is replicated from leader to follower; follower forwards proposals to leader, and leader decides what to commit or not. Leader persists and replicates an entry, once it has been agreed by the quorum of cluster. The underlying storage layer for Raft log is write-ahead log (WAL). Committed entries are written out to disk, so they can be replayed on restart. etcd uses gRPC for transport layer. Client employs HTTP/2 Ping for server health checking, and implements automatic failover under faulty networks. |
There was a problem hiding this comment.
Perhaps worth noting explicitly that leader-based replication does not provide horizontal write scalability. Write (and consistent read) throughput is limited to durable write throughput of a single leader node.
proposals/etcd.adoc
Outdated
|
|
||
| *External dependencies*: https://github.com/coreos/etcd/blob/master/bill-of-materials.json | ||
|
|
||
| *Statement on alignment with CNCF mission*: etcd has enabled adoption of cloud native systems: etcd is "container packaged" by publishing container image for every release, and etcd is a critical component and most reliable storage implementation to many "dynamically managed" systems like Kubernetes. |
There was a problem hiding this comment.
nit: This paragraph could do with some word-smithing. "has enabled adoption" and "most reliable" are strong claims, and unnecessary, IMO, to justify alignment with the CNCF's mission:
|
overall looks reasonable. I agree with @quinton-hoole's nits. |
|
Address @quinton-hoole's feedback. Thanks! |
|
RFC @cncf/toc - will leave this open for a week or so for community feedback |
|
We need to add own, monitor, manage, and maintain discovery.etcd.io to this list as well. etcd-io/etcd#9965 (comment) |
|
@philips That makes sense, since we are donating etcd.io as well. |
proposals/etcd.adoc
Outdated
|
|
||
| *Issue tracker*: https://github.com/coreos/etcd/issues | ||
|
|
||
| *Initial committers*: https://github.com/philips[Brandon Phillips] and |
There was a problem hiding this comment.
If the full list of committers/maintainers is in https://github.com/coreos/etcd/blob/master/MAINTAINERS, then I suggest we remove the 2 specific individuals from here. There are active maintainers from at least Redhat (CoreOS), Amazon, and Google, correct?
There was a problem hiding this comment.
I think there is a misunderstanding of what "Initial Committers" means. Does it mean the people who were initially on the project when it started or the people who will be on the project when donated to CNCF?
For context Xiang and I started the project 5 years ago so I assume that is why we are listed here.
There was a problem hiding this comment.
@bgrant0607 @philips I took this from https://github.com/cncf/toc/blob/master/proposals/grpc.adoc, where initial "git" committers are listed as "Initial committers" (ref. https://github.com/grpc/grpc-java/graphs/contributors?from=2014-05-04&to=2014-09-30&type=c).
There was a problem hiding this comment.
Sorry, this may not be all that important, but perhaps @caniszczyk has guidance.
There was a problem hiding this comment.
@caniszczyk Shall we remove, if this reads confusing?
There was a problem hiding this comment.
@gyuho this means who has commit access to the project when donated, essentially we want to see who has write access, how diverse the committership is etc
There was a problem hiding this comment.
@caniszczyk @bgrant0607 Updated to only list maintainers who have write access to etcd repository. Look forward to expanding more!
proposals/etcd.adoc
Outdated
|
|
||
| *External dependencies*: https://github.com/coreos/etcd/blob/master/bill-of-materials.json | ||
|
|
||
| *Statement on alignment with CNCF mission*: etcd helps adopt cloud native |
There was a problem hiding this comment.
Maybe @philips could help improve the wording here
There was a problem hiding this comment.
@bgrant0607 how about this?
A consistent and partition tolerant datastore, like etcd, is a base dependency for many cloud native architectures. They hold on to critical cluster configuration and locks while providing guarantees against individual machine failure, network partitions, or data center power loss. In the literature and ecosystem etcd, or similar systems (e.g. chubby, zookeeper, etc), provide the persistence layer for applications like Kubernetes, CoreDNS, Vitess, Borg, Mesos, and countless others.
There was a problem hiding this comment.
@philips @bgrant0607 Just updated this part. Thanks!
|
Another question, are you considering making the https://github.com/coreos/etcd-operator part of this contribution? |
|
etcd Operator has not been discussed and isn't part of the proposal so far.
…On Mon, Aug 13, 2018, 2:00 PM Chris Aniszczyk ***@***.***> wrote:
Another question, are you considering making the
https://github.com/coreos/etcd-operator part of this contribution?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#143 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AACDCFK5rOHmOZ3pJkWujtGz8iEGk4VTks5uQej_gaJpZM4V0fgI>
.
|
|
@gyuho Is it correct that etcd has just one repo now? It looks like go-etcd, etcdctl, and etcd-ca repos are deprecated? Is discovery.etcd.io still in use? |
Yes. They were deprecated. All core etcd components (package raft, "etcd" command, "etcdctl" command) are in one https://github.com/coreos/etcd repository.
Some people still use it. @philips should have more data on this. |
proposals/etcd.adoc
Outdated
| See https://github.com/coreos/etcd/blob/master/Documentation/production-users.md[etcd production users] for more. | ||
|
|
||
| Integrations: Kubernetes API server persists cluster metadata in etcd. | ||
| OpenStack uses etcd to keep track service liveness. CockroachDB, TiKV, and |
There was a problem hiding this comment.
Fixed, thanks @jpbetz !
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
|
@bgrant0607 discovery.etcd.io is still in extremely wide use and is used by default in OpenStack spin-up scripts. We had an outage recently on that service and dozens of people noticed on twitter, github, etc. |
|
@caniszczyk where did this end up? |
|
@jonboulle voting is open: https://lists.cncf.io/g/cncf-toc/message/2237 The project team is still finalizing on when they would like to make the announcement, our approach has been to work with the project communities on their preferred time of announcement (there are enough votes for this to technically pass) |
|
+1 binding TOC votes (8/9): Quinton: https://lists.cncf.io/g/cncf-toc/message/2259 Welcome etcd to the CNCF community :) |
ref. #136.
/cc @erinboyd @philips @xiang90 @bgrant0607 @jpbetz @d-nishi