21–30 of 50 posts
I can't figure out what etcd is. Any help?
It is a distributed configuration management clustering product like zookeeper. It simplifies the creation and sharing of mostly configuration data in clustered or distributed systems.
There is more to configuration management that templating files, but in inspection and having other services arriving at other states.
This is a pure marketing story pushing a bad solution. Hiera, a simple hierarchal property distribution system using a backend of Zookeeper plus puppet or chef is far superior. Etcd is the PHP of configuration management.
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.
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 operations as well as what files should contain what. There's not much separating the two because you have to usually change them between states. Chef does this to, but in a simpler way.
Cfengine was a past attempt, but is really complicated double work of what runs on a server and what runs on a managed node.
This is a pure marketing story pushing a bad solution. Hiera, a simple hierarchal property distribution system using a backend of Zookeeper plus puppet or chef is far superior. Etcd is the PHP of configuration management.
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.
This is a pure marketing story pushing a bad solution. Hiera, a simple hierarchal property distribution system using a backend of Zookeeper plus puppet or chef is far superior. Etcd is the PHP of configuration management.
Also never heard of Hiera. I've heard of Zookeeper, Paxos & Raft protocols, also avahi, DNS, LDAP, ansible, saltstack, in other words I am not a total newcomer to system configuration management but am I the only one who hasn't heard of Hiera?
This is a pure marketing story pushing a bad solution. Hiera, a simple hierarchal property distribution system using a backend of Zookeeper plus puppet or chef is far superior. Etcd is the PHP of configuration management.
Why is the solution bad, can you explain? Also never heard of Hiera. I've heard of Zookeeper, Paxos & Raft protocols, also avahi, DNS, LDAP, ansible, saltstack, in other words I am not a total newcomer to system configuration management but am I the only one who hasn't heard of Hiera?
It's bad to promote a solution that don't address the problems of real deployments: coordinating change and responding to it. Updating host files or ssh moduli is about all it seems good for. In reality, files have to be changed at just the right time in a series of coordinated changes with everything else. Chef is what I reach for first, because it solves the problem in the most logical and most complete way. Some people prefer Puppet and that works too. But it's several systems together, like TheForeman (not just Foreman) that make for more powerful infrastructure. There are half a dozen or so other systems in addition to some homegrown (nonportable) ones out there but most others fail to meet requirements Chef and Puppet address (security, auditing, scalability, non/determinism).
Hiera is a like a hierarchal property list that puppet chef etc can use to pull its state. Use zk as a backend to keep multiple instance of hiera in sync to scale for large shops. The neat thing is, like OpenLDAP, Hiera has multiple backends to store your single source of truth. It's like if you wanted to run a Heroku, the environment variables for apps would go in there. Zookeeper is solid but hard to use directly. A more concrete example is a MySQL cluster: you'd want to know what are the hostnames and what is the write master. Sure you could write something that talks to zookeeper but it wouldn't be very general purpose. It's for the use case of scaling beyond what Redis can handle and you do want to get tied to any particular technology other than Hiera. If anyone has funding lying around and wants to take infrastructure smarter and farther, talk to R.I. He knows what the opportunities are and where it needs to go.
http://projects.puppetlabs.com/projects/hiera
PS: I'm glad we're past the days when shops' Cfengine would have a permissions battle with itself (chmod 4750 -> 750 -> 4750 -> ... )
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…
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...
Discovery looks interesting. Can it be used for a client to discover a cluster? I've been digging into Docker link containers a bit. I'm not entirely comfortable with how they work,and I'm not really sure why. The only thing I can put my finger on is that I feel like discovery is a separate concern to deployment. But at the same time they are so closely linked o can understand why Docker needs to tackle it. Is there…
> Discovery looks interesting. Can it be used for a client to discover a cluster? It certainly could be extended for that. We haven't done anything with discovery to help with that process yet though. > Is there a way etcd can work better with Docker links? There is a lot of room to explore here. Including: - Automatically registering exposed ports from running containers into etcd for service discovery. - Using info…
So what is the current best practice for etcd discovery? Environment variable? mDNS might be nice, too (Though I guess mDNS is kinda, almost an alternative for a subset of what etcd does). http://blogs.gnome.org/danni/2014/02/02/a-libnss-plugin-for-... looks interesting too.
I read the Jumper post thing when it was HN. I need to think about that some more.
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…
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 to be coded to use etcd (which is completely different to Chef/Puppet, which are Ops tools). Sure, you could do something to write etcd values to a file, and then have them used by any program, but that misses the point.
Your criticisms are so completely irrelevant they aren't even wrong.
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 you then need to hardcode config information for the second cluster, in which case it serves little purpose.
I'd rather have a mechanism where each peer takes a list of possible peers and tries to connect, with a method for deciding when there is quorum to elect an initial leader and start allowing writes (that's easy enough by introducing a config option to decide if a peer is "blessed" to be part of the initial leadership election, and how many blessed peers must be connected to have quorum - just needs to be enough to form a majority of blessed peers to prevent more than one subset from electing a leader before they manage to connect)
Am I missing something?
Earlier quoted context omitted.
Why is the solution bad, can you explain? Also never heard of Hiera. I've heard of Zookeeper, Paxos & Raft protocols, also avahi, DNS, LDAP, ansible, saltstack, in other words I am not a total newcomer to system configuration management but am I the only one who hasn't heard of Hiera?
There are plenty of good things few people know about. It's bad to promote a solution that don't address the problems of real deployments: coordinating change and responding to it. Updating host files or ssh moduli is about all it seems good for. In reality, files have to be changed at just the right time in a series of coordinated changes with everything else. Chef is what I reach for first, because it solves the pr…
Like Etcd. Or LDAP. Or DNS / Hesiod. Or a directory structure on a network file system. Or about 100 other solutions, many of them decades old (see DNS / Hesiod)
So if you have no arguments for why Etcd is a "bad solution", then why do you claim it is one?
From your little description of Hiera, it doesn't sound like it provides anything particularly interesting for the use-cases I want Etcd for. The appeal of Etcd is simplicity, that Hiera is built on Zookeeper and has multiple backends does not make it appealing.