3 ms·

Automation is not my day job, and I am very happy that there are frameworks (I work with Chef) with communities that offer standards, guidelines and libraries f

by berkes 12y ago

Automation is not my day job, and I am very happy that there are frameworks (I work with Chef) with communities that offer standards, guidelines and libraries for a well maintained set of shell scripts and Makefiles. Instead of having to build and maintain them all myself.

otterley 12y ago
I've sadly learned that given enough time, you'll likely end up mostly using your own set of private cookbooks, even for configuring things community cookbooks already exist for. The quality of the community cookbooks varies wildly from "pretty good" to "toxic waste," and the likelihood of getting fixes upstream fast enough to reflect back into one's own environment is generally low, even for good maintainers. And Chef's strict adherence to X.Y.Z semver for cookbooks (even though cookbooks don't fit semver well) and inability to declare "my cookbook foo_prime can be used whenever cookbook foo is called" makes it near impossible to maintain your own branch while you wait for your fixes to make it upstream. This makes it difficult to try to get things done when you encounter a cookbook that just doesn't work quite right. The cookbook ecosystem is not yet mature enough at this point in time to rely on.
duggan 12y ago
I agree that having standards and best practices is a boon, especially if they can be packaged up in an easy to use way. Like anything, Chef brings its own set of idiosyncrasies to the table. However, I don't like how it brings all of Ruby's idiosyncrasies along for the ride too. If you're not immediately comfortable and familiar with both ruby and the quirks of its ecosystem, you end up investing a lot of time into getting a development environment up and running (and having it reproducible by other members of your team). Most infrastructure tools, if they're any use, are rapidly evolving. Conway's law applies here, and the maintainability of Chef mirrors that of its ruby ecosystem roots - people tend to freeze dependencies rather than upgrade. That's an antipattern we don't need in infrastructure. Honestly I just think we can do better. For me, I'm not sure (read: I really don't know, I'm not being facetious) the costs outweigh the benefits, but for someone totally new, perhaps it helps them get stuff done faster.

by berkes 12y ago

otterley 12y ago

I've sadly learned that given enough time, you'll likely end up mostly using your own set of private cookbooks, even for configuring things community cookbooks already exist for. The quality of the community cookbooks varies wildly from "pretty good" to "toxic waste," and the likelihood of getting fixes upstream fast enough to reflect back into one's own environment is generally low, even for good maintainers. And Chef's strict adherence to X.Y.Z semver for cookbooks (even though cookbooks don't fit semver well) and inability to declare "my cookbook foo_prime can be used whenever cookbook foo is called" makes it near impossible to maintain your own branch while you wait for your fixes to make it upstream. This makes it difficult to try to get things done when you encounter a cookbook that just doesn't work quite right. The cookbook ecosystem is not yet mature enough at this point in time to rely on.

duggan 12y ago

I agree that having standards and best practices is a boon, especially if they can be packaged up in an easy to use way. Like anything, Chef brings its own set of idiosyncrasies to the table. However, I don't like how it brings all of Ruby's idiosyncrasies along for the ride too. If you're not immediately comfortable and familiar with both ruby and the quirks of its ecosystem, you end up investing a lot of time into getting a development environment up and running (and having it reproducible by other members of your team). Most infrastructure tools, if they're any use, are rapidly evolving. Conway's law applies here, and the maintainability of Chef mirrors that of its ruby ecosystem roots - people tend to freeze dependencies rather than upgrade. That's an antipattern we don't need in infrastructure. Honestly I just think we can do better. For me, I'm not sure (read: I really don't know, I'm not being facetious) the costs outweigh the benefits, but for someone totally new, perhaps it helps them get stuff done faster.