[chef] Re: Re: Re: RE: Re: Re: Re: Re: Re: Role Versioning?

[Torben Knerr < >]

+1 for this

Actually I don't know how the search index for "recipe:*" is built. 

Is it built directly from the expanded run_list? 

Or is there a special node attribute like `node[:recipes]` that could be populated with `node.run_state[:seen_recipes]` at the very end of the Chef run?

Hey,I just found the corresponding ticket to up-vote ;-)

http://tickets.opscode.com/browse/CHEF-1977

Cheers, Torben

On Fri, Feb 15, 2013 at 8:41 AM, Adam Jacob < " target="_blank"> > wrote:

We should just fix it, so that recipes included are searchable.

Adam

From: Torben Knerr < " target="_blank"> >
Reply-To: " " target="_blank"> " < " target="_blank"> >
Date: Thursday, February 14, 2013 10:33 PM
To: " " target="_blank"> " < " target="_blank"> >
Subject: [chef] Re: RE: Re: Re: Re: Re: Re: Role Versioning?

Am 15.02.2013 07:09 schrieb "Torben Knerr" < " target="_blank"> >:
>
>
> Am 15.02.2013 04:42 schrieb "Kevin Keane Subscription" < " target="_blank"> >:
>
> >
> > For this exact reason, in my own top-level cookbook, I am not using include_recipe, but rather node.run_list.add (actually, I'm using a mix of the two).
> >
>
> Nice, I didn't think of this possibility yet
>
> > The effect is *almost* the same, but because the recipes are added to the runlist, they are searchable.
> >
> > One difference is that these recipes will not take effect until the *next* chef run.
> >
>
> And that would be the dealbreaker for me.
>
> But: you could probably combine both approaches, i.e. using 'include_recipe' but then do something like this at the end of the chef run:
>
> ruby_block "get_seen_recipes" do
>   block do
>     node.override["knife_audit"]["seen_recipes"] = node.run_state[:seen_recipes]
>     node.run_list.clear
>     node.run_state[:seen_recipes].each do { ¦r¦ node.run_list.add r }
>   end
>   action :create
> end
>
> Are there any reasons against such an approach? For sure, searches for "recipe:*" would only work after the first chef run of the node, but that would not be a big deal.
>

Oh wait - this is borken :-(

=> if you remove an include_recipe or if that include_recipe is skipped due to a conditional, it would require two chef runs to become effective - ugh :-/

> > The second difference is that with include_recipe, you have more control over order-of-execution. In my mind, that's actually a benefit; include_recipe tempts you to think procedurally instead of declaratively.
> >
> > A third difference is that I don't need to declare all the cookbooks as dependency in my top-level cookbook. With include_recipe, I may have dependencies on many cookbooks that aren't even relevant to a particular server. It makes it easier to have a single top-level cookbook for all my servers and use a big case statement to distinguish the servers.
> >
> > Of course you can still declare a dependency in the metadata if you need it to lock down a version number. You just don't *have* to do it for all your recipes.
> >
> >> -----Original message-----
> >> From: Torben Knerr < " target="_blank"> >
> >> Sent: Thursday 14th February 2013 14:21
> >> To: " target="_blank">
> >> Subject: [chef] Re: Re: Re: Re: Re: Role Versioning?
> >>
> >>
> >> The only but very very big limitation of the "application cookbook" / "role cookbook" / "top level cookbook" pattern is that due to the `include_recipe`s the included recipes don't show up in the run_list anymore and thus you can't search for them (which breaks many of the community cookbooks, e.g. apt).
> >>
> >>