ideal0227

9 ms·

31.
by ideal0227 9y ago
There is some overlapping. But we should choose solution wisely :P. Here is a doc [ https://github.com/coreos/etcd/blob/master/Documentation/lea... ] comparing etcd with other systems, including Cockr
32.
Running ZooKeeper apps without ZooKeeper(coreos.com)
2 points by ideal0227 9y ago|0 comments
33.
by ideal0227 10y ago
Well... Why do you need 2PC if nothing is sacrificed? :) If you choose things like Raft (or other RSM), you can get a consistent key space to do txn over keys. For a metadata store like etcd, one RSM group is OK. Performance/availabili
34.
by ideal0227 10y ago
This (like a sharded Raft group) is somewhat correct :P. If you can sacrifice consistency (causal instead of external), you can get EPaxos. If you can sacrifice more, you can get Single Paxos. Both of them can increase concurrency to some d
35.
by ideal0227 10y ago
v3 does not have a native HTTP API. I suspect you still use v2 API. You need the gateway to make v3 works with HTTP: https://github.com/coreos/etcd/blob/master/Documentation/dev... But that might im
36.
by ideal0227 10y ago
etcd v3 read is linearizable by default. Also I believe the authors of the paper tested against the old etcd v2 API/backend although they use etcd3. The new API/backend has significant high performance. I work on etcd.
37.
Run Deep Learning with PaddlePaddle on Kubernetes(blog.kubernetes.io)
3 points by ideal0227 10y ago|0 comments
38.
by ideal0227 10y ago
etcd3 provides a HTTP+JSON API as a gateway: https://github.com/coreos/etcd/blob/master/Documentation/dev... . There are users we know successfully using it. If users are unhappy about the HTTP API,
39.
by ideal0227 10y ago
> the "ease" of etcd seems to have gone Can you explain this more? One of the goals of the new API is to make etcd easier to interact with. Can you provide a few examples where v3 is more difficult than v2 to work with? (etcd-d
40.
by ideal0227 10y ago
Yea. They are similar in functionality. But they work differently. The operator does not really “schedule” containers. It finishes the controlling logic by using Kubernetes APIs. For example, it uses native Kubernetes health checking, servi
41.
by ideal0227 10y ago
The "Chaos Monkey" lives inside the project as a sub-pkg right now: https://github.com/coreos/etcd-operator/tree/master/pkg/chao... . We plan to make it a separate project once we feel good
42.
by ideal0227 10y ago
etcd use bi-directional streams for watchers. One. TCP connections can maintains multiple streams. No matter what you need to keep at least one connection. ZooKeeper is not an exception.
43.
by ideal0227 10y ago
There is a dashboard for publishing the testing result at realtime at http://dash.etcd.io/dashboard/db/functional-tests . The result is not super clear right now, we are improving it.
44.
by ideal0227 10y ago
We are working on it ( https://github.com/coreos/etcd/issues/5067 ). Probably we could work together on the Java client first? It should not be hard given that gRPC supports Java.
45.
by ideal0227 10y ago
Yes. Here: https://godoc.org/github.com/coreos/etcd/clientv3/concurrenc... It would be great if you can provide opinions, comments or help on these high level APIs. We also might move these to an interna
46.
by ideal0227 10y ago
It really depends on how you view the problem. Yes, the latency of agreeing a proposal is similar, which is limited by physical (network latency + disk io). However, there are ways to put more stuff into one proposal (batching) and submitti
47.
by ideal0227 10y ago
Consul: https://github.com/hashicorp/consul/blob/master/bench/result... etcd: https://github.com/coreos/etcd/blob/master/Documentation/op-... Note that the
48.
by ideal0227 10y ago
etcd is based on Raft. Raft has a TLA+ spec. But do note that the implementation usually diverges from its algorithm [0]. For etcd, we try to keep the core algorithm as self-contained and deterministic (no I/O, no timer) as possible. S
49.
by ideal0227 10y ago
etcd3 has similar performance compared to ZK for small scale. For large dataset, etcd3 does better since it does incremental snapshot/ smaller memory footprint, when ZK does full snapshot that takes a lot of resources. For watches, etc
50.
by ideal0227 10y ago
It should not be hard. For v2 API, there are several Java bindings ( https://github.com/jurmous/etcd4j ). For the gRPC API, it is easy to generate a Java gRPC client based on the defined service. We have plans to make th
51.
by ideal0227 10y ago
I think the two projects focus on different things. Consul provides features like health checking, failure detection besides its consistent key-value store. It aims to provide an all-in-one solution[0]. etcd focuses on the consistent key-va
52.
by ideal0227 10y ago
Have you ever thought the etcd issues was just because how you operate it? Or maybe you were running an old version of it? Have you reported to upstream? If there is a very common issue that you can meet frequently, it should have been fixe
53.
by ideal0227 11y ago
tikv's raft is a port of etcd/raft, which is used by a few projects in production. So we can expect rust raft to be mature soon.
54.
by ideal0227 11y ago
Placing quality and throughput are always a tradeoff. Kubernetes, now, uses a naive algorithm that goes over all its nodes and finds the best placement. This is simple and effective for most web workload, when most of your scheduled jobs wi
55.
by ideal0227 11y ago
You are thinking about consistent RSM. Paxos and Raft are not the similar thing and not even at the same level. Epaxos, along with other master-less RSM, does not require heartbeat. It is not about smart people, it is about how you want to
56.
by ideal0227 11y ago
> The problem is the heartbeat; you can't have every node talking to every other node every few seconds. The node does not have to talk with EVERY other nodes. > What we really need is someone smart to come up with a consensus al
57.
by ideal0227 11y ago
Github is not blocked.
58.
by ideal0227 11y ago
We have fixed the SSL issue in 2.1. We are also considering back-port it to 2.0 release if possible.
59.
by ideal0227 12y ago
As a native Chinese, I doubt anyone in Chine knows China good enough. But as a native Chinese, what you should have known is China is growing faster and better in the recent 10 years.
60.
by ideal0227 12y ago
> implicit discrimination towards engineers Never. There is discrimination on social status in China, which is determined by wealth. > In Chinese college, the "elite majors" including cooperation and government management us

More ›