5 ms·

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

by ballard 13y ago

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.

danieldk 13y ago
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.
- ballard 13y ago
  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 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.
  - rdtsc 13y ago
    > 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...
    - ballard 13y ago
      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.
  - nl 13y ago
    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 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.
    - uniclaude 13y ago
      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.
      - nl 13y ago
        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.md https://github.com/coreos/etcd/blob/master/Documentation/api...
      - vidarh 13y ago
        You'd think so, but most RDBMS's are a lot of work to set up in a way that provides the kind of consistency guarantees and availability that a configuration store like this does. E.g. take Postgres. You can't connect to the slaves and write, so your client will need to know how to identify which server is currently the master. And if the master fails, you need to implement a leadership election method, promote the chosen slave, and resync your other slaves from the new master. Before you know it you've reimplemented the configuration store with a different data storage mechanism. There's very little intersection between the typical RDBMS and a configuration store like this.
  - vidarh 13y ago
    > 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.
    - ballard 13y ago
      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.
      - vidarh 13y ago
        > Trying to cast an argument as a strawman with a strawman is pretty weak. I've not presented a strawman. I've pointed out to you that people have different needs. I don't need, nor want what Puppet provides, and Etcd does not claim to provide what Puppet provides. I do, however want what Etcd provides. > You've also admitted that it's an incomplete solution In the sense that a car is an incomplete solution if you need a space shuttle. Yet the car is still more practical if you want to drive on a road. > 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. What basis do you have for that claim?
- deleted 13y ago
  [deleted]
rdtsc 13y ago
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?
- ballard 13y ago
  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 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 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 -> ... )
  - vidarh 13y ago
    > Hiera is a like a hierarchal property list that puppet chef etc can use to pull its state 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.

by ballard 13y ago

danieldk 13y ago

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.

ballard 13y ago
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 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.
- rdtsc 13y ago
  > 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...
  - ballard 13y ago
    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.
- nl 13y ago
  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 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.
  - uniclaude 13y ago
    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.
    - nl 13y ago
      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.md https://github.com/coreos/etcd/blob/master/Documentation/api...
    - vidarh 13y ago
      You'd think so, but most RDBMS's are a lot of work to set up in a way that provides the kind of consistency guarantees and availability that a configuration store like this does. E.g. take Postgres. You can't connect to the slaves and write, so your client will need to know how to identify which server is currently the master. And if the master fails, you need to implement a leadership election method, promote the chosen slave, and resync your other slaves from the new master. Before you know it you've reimplemented the configuration store with a different data storage mechanism. There's very little intersection between the typical RDBMS and a configuration store like this.
- vidarh 13y ago
  > 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.
  - ballard 13y ago
    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.
    - vidarh 13y ago
      > Trying to cast an argument as a strawman with a strawman is pretty weak. I've not presented a strawman. I've pointed out to you that people have different needs. I don't need, nor want what Puppet provides, and Etcd does not claim to provide what Puppet provides. I do, however want what Etcd provides. > You've also admitted that it's an incomplete solution In the sense that a car is an incomplete solution if you need a space shuttle. Yet the car is still more practical if you want to drive on a road. > 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. What basis do you have for that claim?
deleted 13y ago
[deleted]

rdtsc 13y ago

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?

ballard 13y ago
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 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 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 -> ... )
- vidarh 13y ago
  > Hiera is a like a hierarchal property list that puppet chef etc can use to pull its state 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.