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


Chronological Thread 
  • From: Kevin Keane Subscription < >
  • To: < >
  • Subject: [chef] RE: Re: RE: Re: Re: Re: Re: Re: Role Versioning?
  • Date: Thu, 14 Feb 2013 23:43:44 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=sendgrid.info; h=subject :from:to:mime-version:content-type:in-reply-to:references :sender; q=dns; s=smtpapi; b=zhQQRe3q2PtKoP40bxLnmXyR0AoqRd+MHYC oTTT1fHyj9ViuB2ZVs/Z+wMc+tf/aKtVYc5Q9Ip5WK2MexP25rUK7qWY+SDNK0Bb LydNE9DiKW6szebw53gDNRKvJYor+06zkk6eEdx18afyMMr856zguXRej9uPpFw+ pXx1WeGU=

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

.Your mileage may vary. I have no problem with recipes only taking effect the next time, but that's just me. In fact, I actually like it because this way, on the first run on a new node, for the most part only the top-level cookbook will run. That makes for a quick and reliable bootstrapping mechanism.

If you want to get the best of both worlds, you could always do both:

include_recipe "mycookbook"
node.run_list.add("mycookbook")

The recipe will run right away, AND be searchable as soon as the chef run completes (well, OK, after the updated node information has been indexed). On the second run, the cookbook would be called twice, but since chef is declaratory, that shouldn't matter.

As for your concern about removing recipes - good point. In fact, my pattern does have a somewhat unexpected behavior: if you remove a recipe from the runlist using knife, it will come back on the next chef run. My philosophy on that: don't do it. If you use a TLC to manage your runlist, then stick with that.

Another option - conceptually very clean, in my mind: think of the "main" cookbook not as a TLC, but as a complete chef run that sets up a different system (namely, the runlist, as well as any attributes, as needed).

If you want this approach, don't include the TLC in your runlist at all. Instead, write a script that gets called by cron:

chef-client --override-runlist=tlc_cookbook
chef-client

The reason I consider this clean is that in effect, you are simply adding a third phase to a chef run. Instead of compile-execute, we now have setup-runlist/compile/execute.

-----Original message-----
From: Torben Knerr < >
Sent: Thursday 14th February 2013 22:33
To:
Subject: [chef] Re: RE: Re: Re: Re: Re: Re: Role Versioning?


Am 15.02.2013 07:09 schrieb "Torben Knerr" < " target="_blank" title="This external link will open in a new window"> >:
>
>
> Am 15.02.2013 04:42 schrieb "Kevin Keane Subscription" < " target="_blank" title="This external link will open in a new window"> >:
>
> >
> > 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" title="This external link will open in a new window"> >
> >> Sent: Thursday 14th February 2013 14:21
> >> To: " target="_blank" title="This external link will open in a new window">
> >> 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.

§