Live data from Hacker News

Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

coreos.com

31–40 of 50 posts

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#31
post #22

Earlier quoted context omitted.

Wow. I know neither etcd or Hiera. But please provide some arguments against etcd if you think it is bad, rather than just bashing it. It would be interesting to know the cons and pros of both solutions.

I'm bashing it because it oversimplifies the problem and claims to be a solution that doesn't address the irreducibility of the problem. It's great for a host file but scp can do that. It doesn't coordinate the transition of services to other states. Puppet does an incredible amount of work (dependency satisfaction) to get things where you want them to be. Configuration management is as much management order of opera…

> It doesn't coordinate the transition of services to other states.

It's not intended to. It is way outside the scope. But you can easily coordinate transitions on top of Etcd by waiting on key changes.

> Configuration management is as much management order of operations as well as what files should contain what.

Outside of scope. Nothing stops you from using a configuration management engine like Puppet and triggering it on state changes by waiting for Etcd keys. It'd be trivial.

Or use something other than Etcd if those are your needs. But those are not my needs.

For my configuration needs there are exactly no places where I have any interest in the complexity of Puppet, but plenty of places where being able to easily set and query configuration values via a simple REST api that's trivially to access even from a bash script is nice.

You're right that scp can do that. But then you're suddenly in the job of maintaining hairy scripts to push out config changes and ensure they are in sync. So Etcd provides a solution that provides that synchronization without the complexity of far more featureful solutions. To me, that is a feature.

You seem to try to evaluate a handsaw as if it was a chainsaw and give it bad marks for being cumbersome to cut down trees with. Not all of us want to cut down trees.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#32
post #26
post #22

Earlier quoted context omitted.

I'm bashing it because it oversimplifies the problem and claims to be a solution that doesn't address the irreducibility of the problem. It's great for a host file but scp can do that. It doesn't coordinate the transition of services to other states. Puppet does an incredible amount of work (dependency satisfaction) to get things where you want them to be. Configuration management is as much management order of opera…

> It doesn't coordinate the transition of services to other states. Can you be more specific? So to co-ordinate transitions what else would it need -- multi-key transactions? Surely you have good reason to jump in and criticize it so sharply...

Configuration management transactions.

Puppet has the notion of stages.

Yes because it's marketing an unproven technology as a solution when better things already exist. Someone I know from (OpsCode||Puppet) even further the recommendation of zk as basically the only proven consistent KVS. A better approach should be to do what other cloud shops have done and ship ZK appliances. Pushing new tech on customers is using them to beta test unproven tech, which is reinventing the wheel and risky.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#33
post #29

The discovery mechanism looks clumsy to me. There's no way we'd rely on a public discovery service, for example. If we're going to hardcode configuration information - such as the URL of a discovery service that may or may not be up or reachable, we might as well hardcode the addresses of a few peers. And running a second etcd cluster to bring up the main one seems pointless. Either it's turtles all the way down, or…

Quoting the post:

In previous releases, a human had to pick a leader, pass a list of -peers to all of the followers and maintain that list going forward.

Presumably that method is still there?

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#34
post #31
post #22

Earlier quoted context omitted.

I'm bashing it because it oversimplifies the problem and claims to be a solution that doesn't address the irreducibility of the problem. It's great for a host file but scp can do that. It doesn't coordinate the transition of services to other states. Puppet does an incredible amount of work (dependency satisfaction) to get things where you want them to be. Configuration management is as much management order of opera…

> It doesn't coordinate the transition of services to other states. It's not intended to. It is way outside the scope. But you can easily coordinate transitions on top of Etcd by waiting on key changes. > Configuration management is as much management order of operations as well as what files should contain what. Outside of scope. Nothing stops you from using a configuration management engine like Puppet and triggeri…

Trying to cast an argument as a strawman with a strawman is pretty weak.

You've also admitted that it's an incomplete solution. But What's worse is that people are going to buy this and quickly they'll have to scrap it when it gets out of sync, deadlocks or can't handle more than 8 boxes.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#35
post #29

The discovery mechanism looks clumsy to me. There's no way we'd rely on a public discovery service, for example. If we're going to hardcode configuration information - such as the URL of a discovery service that may or may not be up or reachable, we might as well hardcode the addresses of a few peers. And running a second etcd cluster to bring up the main one seems pointless. Either it's turtles all the way down, or…

This is why top-down, single-source of truth is mostly the best way for core infrastructure. No pun intended. It's important for some parts to not be infinitely reconfigurable or dynamic because it would create chaos and service dependency deadlock/DoS. Most people not running bare metal don't know the lessons of how and why things underneath are they way they are and the sensible limits what's possible.

It's also more secure because if it's possible to dictate all of the service details, it's much easier to run a lean and locked-down infrastructure.

CoreOS by itself looks great. More JEOS distros need to happen. Trying to bundle more unproven things just looks marketing led the product.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#37
post #33
post #29

The discovery mechanism looks clumsy to me. There's no way we'd rely on a public discovery service, for example. If we're going to hardcode configuration information - such as the URL of a discovery service that may or may not be up or reachable, we might as well hardcode the addresses of a few peers. And running a second etcd cluster to bring up the main one seems pointless. Either it's turtles all the way down, or…

Quoting the post: In previous releases, a human had to pick a leader, pass a list of -peers to all of the followers and maintain that list going forward. Presumably that method is still there?

Yep, you can still hardcode a list of peers via flag or config file. I think you can even use both a peer list and a discovery token at the same time.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#38
post #29

The discovery mechanism looks clumsy to me. There's no way we'd rely on a public discovery service, for example. If we're going to hardcode configuration information - such as the URL of a discovery service that may or may not be up or reachable, we might as well hardcode the addresses of a few peers. And running a second etcd cluster to bring up the main one seems pointless. Either it's turtles all the way down, or…

Keep in mind that Google's Chubby paper describes a nested series of clusters. You basically have one global cluster that stores the location of the cluster running in each DC. If you're on the west coast and need to read info from the east coast, you can travel up the chain and back down again. At some point you have a single source of truth. This method is basically adding another feature to the global cluster, offering a bootstrapping mechanism for other regional clusters.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#39
post #28
post #22

Earlier quoted context omitted.

I'm bashing it because it oversimplifies the problem and claims to be a solution that doesn't address the irreducibility of the problem. It's great for a host file but scp can do that. It doesn't coordinate the transition of services to other states. Puppet does an incredible amount of work (dependency satisfaction) to get things where you want them to be. Configuration management is as much management order of opera…

I'm not sure what problem you think etcd is attempting to solve, but if your solution involvs Puppet or Chef then it isn't surprising you find etcd isn't sufficient for your purposes. etcd is a highly available configuration store. That's all. It's designed for applications to use to store configuration, so they can be started & stopped without relying on file based storage. Generally speaking these applications have…

No bashing against etcd from me, but can you point me to a reason why a regular database wouldn't work for this type of thing?

High availability, throughput and data storage seem to fit into what a database is made for.

Re: Etcd 0.3.0 – Improved Cluster Discovery, API Enhancements and Windows Support

#40
post #28

Earlier quoted context omitted.

I'm not sure what problem you think etcd is attempting to solve, but if your solution involvs Puppet or Chef then it isn't surprising you find etcd isn't sufficient for your purposes. etcd is a highly available configuration store. That's all. It's designed for applications to use to store configuration, so they can be started & stopped without relying on file based storage. Generally speaking these applications have…

No bashing against etcd from me, but can you point me to a reason why a regular database wouldn't work for this type of thing? High availability, throughput and data storage seem to fit into what a database is made for.

The HTTP based interface[1] is designed specifically for configuration data and is easily callable from shell scripts as well as form programs.

Something like CouchDB is roughly comparable in that sense, but that has pretty different design goals.

[1] https://github.com/coreos/etcd/blob/master/Documentation/api...

Post reply on HN