Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing zetcd

coreos.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Introducing zetcd

#11

Post by philips »

ninjakeyboard wrote: post #10

So how does zetcd handle the zookeeper session? It's in zetcd and then the "ephemeral nodes" are removed from etcd if the zk client session expires? This is handled by the proxy? This seems to be the major design compatibility item between the two is that the zookeeper protocol has a session state and so supports ephemeral nodes. If a gc pauses the jvm for a long time the client session will expire. In etcd there is…

A Go routine is spawned which runs the etcd client's KeepAlive method to tie a session to a lease in the proxy. The code is here: https://github.com/coreos/zetcd/blob/d33e3b836a2a2de8a8ec077...

Disclaimer: The person who wrote this is AFK at the moment so I might be completely wrong ;)

Re: Introducing zetcd

#12

Post by tyingq »

philips wrote: post #9
tyingq wrote: post #8

Earlier quoted context omitted.

Yes, you can sort of detune the whole cluster. That's not quite the same as Consul's and CockroachDB's specific WAN awareness. Those two take different approaches, but do specifically understand and compensate. >What is your use case? Contract work, so use case varies. I agree that etcd is often the right answer.

Right, etcd's entire focus is on being a consensus database for distributed systems needing coordination, locking, etc. So, eventually consistent WAN replication hasn't really been a focus. I do think this sort of cross-cluster key replication is useful and we offer it as a userspace external tool called make-mirror[1]. [1] https://github.com/coreos/etcd/blob/master/etcdctl/README.md...

Worth noting that CockroachDB isn't using an eventually consistent model. Yes, it's not the same thing as etcd, but I can see some potential use case overlap.

Re: Introducing zetcd

#13

Post by ideal0227 »

tyingq wrote: post #12
philips wrote: post #9

Earlier quoted context omitted.

Right, etcd's entire focus is on being a consensus database for distributed systems needing coordination, locking, etc. So, eventually consistent WAN replication hasn't really been a focus. I do think this sort of cross-cluster key replication is useful and we offer it as a userspace external tool called make-mirror[1]. [1] https://github.com/coreos/etcd/blob/master/etcdctl/README.md...

Worth noting that CockroachDB isn't using an eventually consistent model. Yes, it's not the same thing as etcd, but I can see some potential use case overlap.

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 CockroachDB.

I work on etcd.

Re: Introducing zetcd

#14

Post by manojlds »

philips wrote: post #5

A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications. The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API. apiVersion: "etcd.coreos.com/v1beta1" kind: "Cluster" metadata: name: "examp…

So I can run a Kubernetes cluster on Mesos and have the Zookeeper for Mesos deployed on the Kubernetes cluster using the etcd operator and zetcd

Joking, of course.

Re: Introducing zetcd

#15

Post by koolba »

manojlds wrote: post #14
philips wrote: post #5

A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications. The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API. apiVersion: "etcd.coreos.com/v1beta1" kind: "Cluster" metadata: name: "examp…

So I can run a Kubernetes cluster on Mesos and have the Zookeeper for Mesos deployed on the Kubernetes cluster using the etcd operator and zetcd Joking, of course.

The funny thing about the situation you describe is that there are real world examples of similar circular dependencies.

I recall GitHub having an issue like that where their build pipeline used Bower which is hosted on GitHub. When shit hit the fan and a build broke the site, they could build the "fix" as Bower didn't work.

Re: Introducing zetcd

#16

Post by jzelinskie »

koolba wrote: post #15
manojlds wrote: post #14

Earlier quoted context omitted.

So I can run a Kubernetes cluster on Mesos and have the Zookeeper for Mesos deployed on the Kubernetes cluster using the etcd operator and zetcd Joking, of course.

The funny thing about the situation you describe is that there are real world examples of similar circular dependencies. I recall GitHub having an issue like that where their build pipeline used Bower which is hosted on GitHub. When shit hit the fan and a build broke the site, they could build the "fix" as Bower didn't work.

My own experience working at CoreOS is that many of our projects exploit self-referentiality as it's a particularly useful property.

Off the top of my head:

- Quay.io, our registry service, is built and deployed by itself

- Clair, our static analysis tool for detecting security vulnerabilities, analyzes itself

- Tectonic, our enterprise Kubernetes distro, is "self-driving" and manages itself

- discovery.etcd.io, a service we run to make it easier to bootstrap new etcd quorums, is just a quorum of etcd nodes

Re: Introducing zetcd

#17

Post by [deleted] »

jzelinskie wrote: post #16
koolba wrote: post #15

Earlier quoted context omitted.

The funny thing about the situation you describe is that there are real world examples of similar circular dependencies. I recall GitHub having an issue like that where their build pipeline used Bower which is hosted on GitHub. When shit hit the fan and a build broke the site, they could build the "fix" as Bower didn't work.

My own experience working at CoreOS is that many of our projects exploit self-referentiality as it's a particularly useful property. Off the top of my head: - Quay.io, our registry service, is built and deployed by itself - Clair, our static analysis tool for detecting security vulnerabilities, analyzes itself - Tectonic, our enterprise Kubernetes distro, is "self-driving" and manages itself - discovery.etcd.io, a se…

[deleted]

Re: Introducing zetcd

#19

Post by agibsonccc »

philips wrote: post #5

A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications. The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API. apiVersion: "etcd.coreos.com/v1beta1" kind: "Cluster" metadata: name: "examp…

Who are you targeting with this? The "hesitant" zookeeper folks that already depend on etcd? Are you hoping to unseat cdh here? Pardon the naive question here - I never bump in to k8s selling to traditional enterprise hadoop customers.

I'd also never pick kubernetes for my "from scratch" cluster due to already being reliant on the JVM stack. I actually like the idea of giving an IT department that already understands zookeeper a mesos cluster with DC/OS.

That being said - k8s has a ton of momentum but it seems to be mainly with startups or maybe niche teams (prove me wrong here?) outside of google. It would be great to understand what you guys are looking at for things like this. Right now it feels like k8s and a lot of the other startups in this space like pachyderm are trying to compete with the hadoop ecosystem (which is great! competition forces innovation which is good for the ecosystem as a whole)

Re: Introducing zetcd

#20

Post by jaz46 »

agibsonccc wrote: post #19
philips wrote: post #5

A big use case of this that we are thinking about is enabling people to use the etcd Operator[1], which makes it simple to run etcd clusters on Kubernetes, to back their ZooKeeper applications. The neat thing about the etcd Operator is you can define a cluster and the etcd Operator takes care of normal operations by using the Kubernetes API. apiVersion: "etcd.coreos.com/v1beta1" kind: "Cluster" metadata: name: "examp…

Who are you targeting with this? The "hesitant" zookeeper folks that already depend on etcd? Are you hoping to unseat cdh here? Pardon the naive question here - I never bump in to k8s selling to traditional enterprise hadoop customers. I'd also never pick kubernetes for my "from scratch" cluster due to already being reliant on the JVM stack. I actually like the idea of giving an IT department that already understands…

Kubernetes is actually getting a solid amount of large-tech and early adopter enterprise deployment. That's still pretty nascent, but it's picking up quickly. Happy to discuss in more details offline the adoption we're seeing.

The reason you don't bump into k8s while selling to Hadoop users is that Hadoop isn't something you'd run on a container-based stack (at least not right now and IMO it wont be). There are lots of Hadoop users who run containers for their application infra (as opposed to data infra). Pachyderm's whole pitch is that containerized data infra can be really powerful and that enterprises will want to unify their stack to all be containerized and k8s is THE answer for the orchestration layer.

P.S. Despite all my opinions above, I actually agree with your initial question around who zetcd is actually targeting. I don't have a clear picture of that.

Post reply on HN