7 ms·

Chef requires Ruby programming. Puppet doesn't, but the core is obviously Ruby, and you extend it using Ruby. You may possibly like my new project: http://an

by mdehaan 14y ago

Chef requires Ruby programming. Puppet doesn't, but the core is obviously Ruby, and you extend it using Ruby. You may possibly like my new project: http://ansible.github.com http://ansible.github.com The core is Python but you can write modules in any language.

mixmastamyk 14y ago
Cool, I'm also investigating the python-based salt stack: http://saltstack.org/ http://saltstack.org/ for this purpose but it seems a bit heavy just starting out. Gonna try ansible next.
- emidln 14y ago
  Currently deploying salt. Community is great, grains are easy to write, and the codebase is very clear. Can't recommend enough.
davecap1 14y ago
There is also cuisine, which brings chef-like functionality to fabric. https://github.com/sebastien/cuisine https://github.com/sebastien/cuisine
pconf 14y ago
Thanks for that! We gave up on chef when one of their version updates failed to work with a prior version, both of which were the OS package defaults. Chef silently failed, no error message, nothing in the docs, nothing even in the source code. Had to do a fair bit of searching to find out why. When open source projects like chef have nobody interested in even documenting much less testing backwards incompatibilities we move them to the bottom of our to-eval list. This also illustrates a problem in article's blind enthusiasm for the latest revisions and libraries i.e., it dismisses the headaches this causes end-users, who often don't have staff or budget to fix whatever breaks during an upgrade. That said we are at least talking about python, which has had better release QA and backwards compatibility than perl, ruby or, gasp, php.
- chromatic 14y ago
  That said we are at least talking about python, which has had better release QA and backwards compatibility than perl.... I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?
  - pconf 14y ago
    We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.
    - chromatic 14y ago
      That makes sense. XS components (compiled code which uses the Perl API) don't have binary backwards compatibility between major Perl releases.
      - pconf 14y ago
        The audio library incompatibilities were API changes. Amavisd's issues are not binary either but do seem mostly socket related.

by mdehaan 14y ago

mixmastamyk 14y ago

Cool, I'm also investigating the python-based salt stack: http://saltstack.org/ http://saltstack.org/ for this purpose but it seems a bit heavy just starting out. Gonna try ansible next.

emidln 14y ago
Currently deploying salt. Community is great, grains are easy to write, and the codebase is very clear. Can't recommend enough.

davecap1 14y ago

There is also cuisine, which brings chef-like functionality to fabric. https://github.com/sebastien/cuisine https://github.com/sebastien/cuisine

pconf 14y ago

Thanks for that! We gave up on chef when one of their version updates failed to work with a prior version, both of which were the OS package defaults. Chef silently failed, no error message, nothing in the docs, nothing even in the source code. Had to do a fair bit of searching to find out why. When open source projects like chef have nobody interested in even documenting much less testing backwards incompatibilities we move them to the bottom of our to-eval list. This also illustrates a problem in article's blind enthusiasm for the latest revisions and libraries i.e., it dismisses the headaches this causes end-users, who often don't have staff or budget to fix whatever breaks during an upgrade. That said we are at least talking about python, which has had better release QA and backwards compatibility than perl, ruby or, gasp, php.

chromatic 14y ago
That said we are at least talking about python, which has had better release QA and backwards compatibility than perl.... I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?
- pconf 14y ago
  We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.
  - chromatic 14y ago
    That makes sense. XS components (compiled code which uses the Perl API) don't have binary backwards compatibility between major Perl releases.
    - pconf 14y ago
      The audio library incompatibilities were API changes. Amavisd's issues are not binary either but do seem mostly socket related.