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

[AJ Christensen < >]

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.

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.

 [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.