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

[John Vincent < >]

On Wed, Mar 21, 2012 at 4:38 PM, AJ Christensen 
<
 >
 wrote:
> Sorry for top post, pre-coffee email;
>
> Just wanted to suggest that you guys actually test the functionality
> before getting evangelical -- it was trivial for me to overlook this
> as hogwash without building a gem and actually testing the different
> modes as I couldn't conjure a use case out of thin air -- mostly came
> up with "what the hell is this crap why would anyone want to do this?"
> the first time I looked at the feature request.
>
> Some cool behaviour that I hadn't considered was actually possible
> e.g.: an approximation of multi-platform cookbook dependencies with
> components disabled for particular suites (with client/solo config)..
> This can easily solve the age-old apt/yum/.../pacman? multiple
> cookbook dependency, only run the right one. So too could another
> level of abstraction designed specifically for this purpose, if that
> is what we are solving for.
>

IMHO that problem should be resolved with support inside chef. We have
file and template locality. That should be moved up the stack somehow.

I'm a huge hater of needing conditionals but we have a process that,
while under utillized by most folks, is pretty damn powerful. It just
needs to be expanded conceptually.

> I am querying our client who requested CHEF-2988 to weigh on in the
> mailing list with their original requirements that lead to it being
> developed. Hopefully that provides a little context.
>
> I can't imagine this hurting a new user -- if you restrict a recipe,
> the including, and included recipes are not run. It's basic. Shit just
> runs or it doesn't, and it is noisy about it. You don't have to guess.
> I can see some complexity when a new user is restricting parts of his
> environment from running without considering the implications, which I
> guess is what everyone is worried about -- dumb people doing dumb
> shit.
>
> Said new user would receive multiple warnings and in the event she
> were to seek help this would be obvious to a skilled operator.
>

Imho someone shouldn't need to seek help for something like this. The
only justifications I've heard thus far are:

1) my runs take too long
2) I want to do a one off thing

Again, the conditional aspect is nice but I'd much rather it be
formalized in different way akin to how locality works now.

>  [I have cc'd some of the users involved in the internal testing of
> the functionality]
>
> --AJ
>
> On 22 March 2012 08:53, Bryan Berry 
> <
 >
>  wrote:
>> My gut agrees w lusis.
>>
>> Avoiding unwanted behavior should really be dealt with via disciplined use
>> if git. If enterprise customers have big chef servers with too many
>> sysadmins and too many cookbooks uploaded, I think they might be better
>> served by having multiple chef servers
>>
>> On Mar 21, 2012 8:22 PM, "John Vincent" 
>> <
 >
>> wrote:
>>>
>>> On Wed, Mar 21, 2012 at 3:06 PM, Bryan McLellan 
>>> <
 >
>>>  wrote:
>>> > Let's talk about this patch and what the design gives us versus what
>>> > it locks us into.
>>> >
>>> > -----------
>>> > http://tickets.opscode.com/browse/CHEF-2988 - Run List Modifiers
>>> >
>>> > Provides three new options to modify run lists:
>>> >
>>> > --allowed-recipes: Restricts what recipes are allowed in the run list
>>> > to only those provided. This restriction is not applied to recipe
>>> > dependencies.
>>> > --restricted-recipes: Restricts provided recipes from running. If a
>>> > restricted recipe is a dependency of another recipe, neither are
>>> > allowed to run.
>>> > --override-runlist: Replaces the current run list with provided run
>>> > list. This override is only applied for the current run.
>>> > -----------
>>>
>>> My personal opinion is that it's a hack and encourages bad practice.
>>> If your client runs are slow, fix that. If you don't trust your runs,
>>> fix that. This is a path of madness and surprises all the way around.
>>>
>>> Again, personal opinion.