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


Chronological Thread 
  • From: John Vincent < >
  • To: Adam Jacob < >
  • Cc: AJ Christensen < >, , Bryan Berry < >, Bryan McLellan < >, Darrin Eden < >, sean escriva < >
  • Subject: [chef-dev] Re: Re: Re: Re: CHEF-2988 allowed_recipes, restricted_recipes, and override_recipes
  • Date: Wed, 21 Mar 2012 22:08:23 -0400

On Wed, Mar 21, 2012 at 9:55 PM, Adam Jacob 
< >
 wrote:
> On Wed, Mar 21, 2012 at 1:44 PM, John Vincent
> < >
>  wrote:
>> 1) my runs take too long
>> 2) I want to do a one off thing
>
> So, besides the fact that some users want to do what you feel like is
> a bad thing, is there a reason not to include it?
>

Fair question. The easy answer is no. There is absolutely no reason
*technically* not to include it.

> I think it's a bad idea (tm) to do one-off runs without having done a
> complete converge in the near-term past (the side effects demand it!)
> - but I can see the value in doing something like this for things like
> triggered application deployments, where I know I want to trigger a
> single subset of the run list.
>
> My feeling is we shouldn't dismiss functionality some set of us find
> useful simply out of dogmatic adherence to a model another (probably
> majority) of us *do* like, unless it's really damaging to Chef. I
> don't see how this is, other than being a little afraid of what
> happens in infrastructure that relies on it a lot.
>

I see it a bit different than dogmatic adherence. I see it as setting
an example of best practices.
There's a reason Chef doesn't (or rather didn't depending) have a dry
run. This is sort of the same thing. I'm not saying not to listen to
the community and Jupiter knows there are more people contributing
code right now than me. My personal opinion is that, regardless of the
tool in question, it should espouse what it feels are best practices.
I hate Maven with the fire of 20 million suns but one thing Maven does
is stick to what it considers best practices.

Maybe that's MORE of an argument for allowing it than not. Maven makes
it impossible to step outside its world.

> Nothing stops us from shipping it and making it obsolete by having a
> more awesome way to do it.
>

This is true but it's harder to remove a feature than add one. Like I
said, I'd rather see the "root" problem addressed instead of adding on
a possible dangerous short-term fix.

> Adam
>
> --
> Opscode, Inc.
> Adam Jacob, Chief Customer Officer
> T: (206) 619-7151 E: 
> 



Archive powered by MHonArc 2.6.16.

§