[chef-dev] Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes

[Bryan McLellan < >]

We discussed this at length today at the OSS review meeting and we had
this discussion in two steps. First we looked at the proposed features
and then we looked at the implementation. I'll save the technical bits
for the CHEF-2988 ticket.

As a feature, we like an override runlist (or one-shot runlists).
We've talked for years about implementing a feature (opscode-agent
anyone?) that allows you to push a runlist out to a node or a subset
of nodes from a central location. Consider a situation where someone
from IT needs to remove the user account of a developer who has left
the company. The IT staff should be able to run their users cookbook
across the entire infrastructure without worry about the state of the
application cookbooks, even if by best practice it should be fine.
With this feature, someone could run 'knife ssh *:* sudo chef-client
-o recipe[users]'. We're still planning a more elaborate trigger
mechanism at Opscode than this. In the interim, this feature is a step
in the right direction.

Again, as features, we're not convinced that the value of allowed and
restricted cookbooks are greater than what you can do with an override
runlist. Also we acknowledge that accepting these features comes at
the expense of added complexity to the user. This is part of the
"lockin" that I hinted at in my original mail to the list. The
individual issues that I found such as logging and accepting a
RunListItem where a recipe name was expected are certainly solvable,
but these underscore the cost of adding features like this upon a
broad community of users.

One use case presented was needing to prevent a yum cookbook from
being run on an Ubuntu system, which is preventing you from doing an
application deployment. However, this case can be handled will an
override run list without cost of an additional feature.

A feature that we do want is failure zones, which is the ability to
group multiple run_lists such that one group can continue to run even
if another fails [1]. We believe this feature should be built from the
top-down as it requires the ability to set the permanent run list of a
node to specify these groupings on the server and will likely affect
other areas of the Chef run such as saving the node and running report
handlers. The allowed and restricted cookbook features are not a
failure zone implementation of any kind, because they require the user
to manually trigger another run with a different grouping if the
original grouping failed. Thus we forgo these features in favor of a
future implementation of failure zones.

-- 
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

[1] http://tickets.opscode.com/browse/CHEF-2070