On Jun 6, 2013, at 9:46 AM, Matt Whiteley firstname.lastname@example.org wrote:
cookbook metadata should include maintainer_repository
The depends cookbook DSL should take an optional platform_family argument
Implement cookbook metadata “suggests” and "recommends"
Enforce / Implement platform “supports” in cookbook metadata
Thanks for collecting these into a handy single list
The problem that we are having occurs when a mandatory cookbook’s dependencies change based on attributes. As others have described, this can cause issues of slowness or confusion when cookbooks unsupported on the client system are required. As an example, I would like to develop a cookbook that will require the MySQL or PostgreSQL cookbooks but can also ignore this dependency with an unset db_type attribute.
The thing about attributes is that it is very common to set behavior in a cookbook based on the value of an attribute, and to set the default value of said attributes based on the node’s platform.
A particular cookbook might be specifically supported/tested on a certain platforms (like, “Debian” or “CentOS”). It might “just work” on other platforms without modification. It might require modifying attributes, or retrieving additional dependencies.
Generally many cookbooks “just work” because the [metadata] dependencies are set to cover the various use cases from the attributes. I think this is good, and it is the least surprising thing to most people.
However, it does mean you may end up with code you don’t need on your nodes. For example, the “git” cookbook supports installing the ‘git’ package on a variety of platforms including Windows. This means, due to the lack of a “package” resource in Core Chef for Windows (yet), we need the windows cookbook, which has
windows_package. If we don’t, then anyone who wants to just drop ‘recipe[git]’ on a Windows node will get an exception, find the need to get the windows cookbook, and wonder why Chef doesn’t support Windows as a first class citizen.
Also, the git cookbook supports setting up a Git server. This brings in a dependency on runit, because we use a runit service to set up the daemon. This means that people who just want the git package so they can use the tool on their system may be confused why they have runit (they don’t use runit, they use sysv/init, wtf!).
This goes on and on for various cookbooks, use cases, platforms. It’s a fairly nuanced and difficult problem to solve. Someone will always be confused or irritated with this, because either:
- things don’t work by default without more effect (and domain knowledge), or
- they have a bunch of code they didn’t want/need being transferred about.
Comments in the tickets keeps the conversation in one place, but for folks who wish to contribute a fix for this, we need to ensure that we’re consistent across the various codebases where this is affected (chef client, chef server, cookbook metadata).
Thank you for bringing this up!
: We’re working on adding a package resource for Windows, so the
windows cookbook is no longer required, but I don’t have an ETA.
: I don’t feel this is true, but it feels that way when we have things like this :(.