20 ms·

The linked article is about package management, not configuration management. Whoever set the title of this post didn't understand the point of the article. Fro

by shaggy 13y ago

The linked article is about package management, not configuration management. Whoever set the title of this post didn't understand the point of the article. From the comments, people seem to confuse and conflate configuration management, job automation and package management. To run a successful infrastructure at any scale you need all three.

StavrosK 13y ago
If it's about package management, why did it even talk about Chef, Ansible, etc? It seems to me that the package management changes he describes can be exposed at a top-level layer of "tell me which packages and versions you want", which has NOTHING to do with the configuration managers he mentions. Literally every single one of the tools he said we can do better than, could use his package manager with almost no changes.
- leoc 13y ago
  Imagine a world in which the treatment for heart attacks was to get the victim to sit down and press icepacks to their chest. Someone writes an article about "Why icepacks aren't good enough" as treatments for cardiac arrest. It would be clear why the article started by talking about icepacks.
  - StavrosK 13y ago
    Not really. He's complaining about Ansible/Chef/etc when they have nothing to do with the real issue, which is package management. The rest is just tangential.
    - leoc 13y ago
      As best I understand: he explains why you see certain problems when using the Ansible/Chef etc. (the icepack) and then explains why these are symptoms of underlying problems with package management (the heart-attack) which can't be resolved through the use of an icepack.
      - StavrosK 13y ago
        I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur. You can specify the packages you want in Ansible, and it will abstract away everything else, giving you what you asked for. Ansible's config language wouldn't look any different if it were using nix (and it probably can), so what he says doesn't follow: Ansible (et al) aren't enough => We improve a part of the underlying system => Ansible looks exactly the same, but is magically now enough.
        cwp 13y ago
        No. It's this: Ansible (et al) aren't enough => We improve a part of the underlying system => We build a new tool that makes use of the improvements and is therefor better than Ansible. https://github.com/NixOS/nixops https://github.com/NixOS/nixops
        mercurial 13y ago
        > I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur. There is a fundamental difference between Ansible and co. and NixOS. These tools take you from an unknown state, look at the part of this state you configured in the Ansible files, and apply the modifications necessary. NixOS will take its cue from a single file (possibly with includes) describing the entire machine. Concretely, if you tell Ansible "package X should be present", apply the configuration and then remove this line before reapplying the configuration, package X will still be present, even though it's not listed in the configuration. I don't mean that as a criticism of Ansible, for my purpose it's about as good as it gets, but it's two different paradigms.
      - cls59 13y ago
        Right. But enforcing state in the packaging system is only one facet of what configuration management tools are used for. Building a better package manager won't remove the need for configuration management tools. The problems that gave arise to these tools extend far beyond package management and cannot be reduced to package management as a root cause.
pmahoney 13y ago
What's the difference between a "package" and a "configuration"? At some level, they are both sets of files, so I can imagine a tool handling both, providing the benefit of a common interface. On the other hand, why might one want separate tools for packages and configuration?
- sp332 13y ago
  A package is more loosely defined. You can have the same Apache package installed with vastly different configurations. A configuration is a lot more specific.
- jzwinck 13y ago
  A package is a product, a cooked thing like Nginx. A configuration is ephemeral and site-specific, a dynamic thing like ~/.bashrc. You can claim the two are really the same, but no one else will understand what you are on about (is he saying we should hard-code more stuff?). We don't need exactly two categories here, but that seems the most idiomatic, and has done for decades. Individual users may benefit from versioning their config files, but usually not their programs. Big business might do both, or just as likely screw it up and version code but not configs (I'm looking at you, crontab).
  - peterwwillis 13y ago
    Some people 'cook' their configuration into packages because they aren't allowed to change the configuration on the target. You can also generalize 'automation' to mean configuration management, package management, job management, bug management, change management, deployment, monitoring, continuous deployment/delivery, continuous integration, and many other fields. In practice, everybody screws something up, whether individually or part of a small/big business. The tools are typically not the problem; the humans and how they use them, are.
  - derefr 13y ago
    What he's talking about is likely this strategy: https://wiki.debian.org/ConfigPackages https://wiki.debian.org/ConfigPackages If you follow it, you'll get a package like "mycorp-nginx", which is an atomic piece of configuration management that not only controls nginx's configuration wherever you deploy it, but also nginx's version on those same machines. Basically, with this strategy, instead of installing nginx, you only install mycorp-nginx; the config-package then installs the thing it's configuring as a dependency. That dependency is locked to a specific version, so it'll only upgrade when you push out a config-package that changes that dependency.
copergi 13y ago
>The linked article is about package management, not configuration management The whole point is that those aren't different things. Once you create a proper package management system, it is also a proper configuration management system. The article didn't do a great job of explaining it, but fire up a few VMs and give NixOps a try.

by shaggy 13y ago

StavrosK 13y ago

If it's about package management, why did it even talk about Chef, Ansible, etc? It seems to me that the package management changes he describes can be exposed at a top-level layer of "tell me which packages and versions you want", which has NOTHING to do with the configuration managers he mentions. Literally every single one of the tools he said we can do better than, could use his package manager with almost no changes.

leoc 13y ago
Imagine a world in which the treatment for heart attacks was to get the victim to sit down and press icepacks to their chest. Someone writes an article about "Why icepacks aren't good enough" as treatments for cardiac arrest. It would be clear why the article started by talking about icepacks.
- StavrosK 13y ago
  Not really. He's complaining about Ansible/Chef/etc when they have nothing to do with the real issue, which is package management. The rest is just tangential.
  - leoc 13y ago
    As best I understand: he explains why you see certain problems when using the Ansible/Chef etc. (the icepack) and then explains why these are symptoms of underlying problems with package management (the heart-attack) which can't be resolved through the use of an icepack.
    - StavrosK 13y ago
      I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur. You can specify the packages you want in Ansible, and it will abstract away everything else, giving you what you asked for. Ansible's config language wouldn't look any different if it were using nix (and it probably can), so what he says doesn't follow: Ansible (et al) aren't enough => We improve a part of the underlying system => Ansible looks exactly the same, but is magically now enough.
      - cwp 13y ago
        No. It's this: Ansible (et al) aren't enough => We improve a part of the underlying system => We build a new tool that makes use of the improvements and is therefor better than Ansible. https://github.com/NixOS/nixops https://github.com/NixOS/nixops
      - mercurial 13y ago
        > I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur. There is a fundamental difference between Ansible and co. and NixOS. These tools take you from an unknown state, look at the part of this state you configured in the Ansible files, and apply the modifications necessary. NixOS will take its cue from a single file (possibly with includes) describing the entire machine. Concretely, if you tell Ansible "package X should be present", apply the configuration and then remove this line before reapplying the configuration, package X will still be present, even though it's not listed in the configuration. I don't mean that as a criticism of Ansible, for my purpose it's about as good as it gets, but it's two different paradigms.
    - cls59 13y ago
      Right. But enforcing state in the packaging system is only one facet of what configuration management tools are used for. Building a better package manager won't remove the need for configuration management tools. The problems that gave arise to these tools extend far beyond package management and cannot be reduced to package management as a root cause.

pmahoney 13y ago

What's the difference between a "package" and a "configuration"? At some level, they are both sets of files, so I can imagine a tool handling both, providing the benefit of a common interface. On the other hand, why might one want separate tools for packages and configuration?

sp332 13y ago
A package is more loosely defined. You can have the same Apache package installed with vastly different configurations. A configuration is a lot more specific.
jzwinck 13y ago
A package is a product, a cooked thing like Nginx. A configuration is ephemeral and site-specific, a dynamic thing like ~/.bashrc. You can claim the two are really the same, but no one else will understand what you are on about (is he saying we should hard-code more stuff?). We don't need exactly two categories here, but that seems the most idiomatic, and has done for decades. Individual users may benefit from versioning their config files, but usually not their programs. Big business might do both, or just as likely screw it up and version code but not configs (I'm looking at you, crontab).
- peterwwillis 13y ago
  Some people 'cook' their configuration into packages because they aren't allowed to change the configuration on the target. You can also generalize 'automation' to mean configuration management, package management, job management, bug management, change management, deployment, monitoring, continuous deployment/delivery, continuous integration, and many other fields. In practice, everybody screws something up, whether individually or part of a small/big business. The tools are typically not the problem; the humans and how they use them, are.
- derefr 13y ago
  What he's talking about is likely this strategy: https://wiki.debian.org/ConfigPackages https://wiki.debian.org/ConfigPackages If you follow it, you'll get a package like "mycorp-nginx", which is an atomic piece of configuration management that not only controls nginx's configuration wherever you deploy it, but also nginx's version on those same machines. Basically, with this strategy, instead of installing nginx, you only install mycorp-nginx; the config-package then installs the thing it's configuring as a dependency. That dependency is locked to a specific version, so it'll only upgrade when you push out a config-package that changes that dependency.

copergi 13y ago

>The linked article is about package management, not configuration management The whole point is that those aren't different things. Once you create a proper package management system, it is also a proper configuration management system. The article didn't do a great job of explaining it, but fire up a few VMs and give NixOps a try.