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


Chronological Thread 
  • From: Adam Jacob < >
  • To: " " < >
  • Subject: [chef] Re: Re: RE: Re: Re: Re: Re: Re: Role Versioning?
  • Date: Fri, 15 Feb 2013 07:41:29 +0000
  • Accept-language: en-US

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

Adam



Am 15.02.2013 07:09 schrieb "Torben Knerr" < "> >:
>
>
> Am 15.02.2013 04:42 schrieb "Kevin Keane Subscription" < "> >:
>
> >
> > 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 < "> >
> >> Sent: Thursday 14th February 2013 14:21
> >> To: ">
> >> 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).
> >>
> >>




Archive powered by MHonArc 2.6.16.

§