[chef] Re: Conditional dependencies

[Joshua Timberman < >]

Ohai,

On Jun 6, 2013, at 9:46 AM, Matt Whiteley 
<
 >
 wrote:

> cookbook metadata should include maintainer_repository
> http://tickets.opscode.com/browse/CHEF-286
> 
> The depends cookbook DSL should take an optional platform_family argument
> http://tickets.opscode.com/browse/CHEF-3282
> 
> Implement cookbook metadata "suggests" and "recommends"
> http://tickets.opscode.com/browse/CHEF-3270
> 
> Enforce / Implement platform "supports" in cookbook metadata
> http://tickets.opscode.com/browse/CHEF-3871

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[0]), 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[1].

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: 

1. things don't work by default without more effect (and domain knowledge), or
2. 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!

Cheers,
Joshua

[0]: 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.
[1]: I don't feel this is true, but it feels that way when we have things 
like this :(.