Re: attribute value availability + the implicit dependency graph and chef-deploy patch


Chronological Thread 
  • From: Adam Jacob <adam@opscode.com>
  • To: chef@lists.opscode.com
  • Subject: Re: attribute value availability + the implicit dependency graph and chef-deploy patch
  • Date: Thu, 23 Apr 2009 13:47:27 -0700

On Thu, Apr 23, 2009 at 12:46 PM, Ian Kallen <spidaman.list@gmail.com> wrote:
> Great, thanks Adam. Let me make sure I'm following the semantics. Given N
> cookbooks, the order in which each of the respective attributes loaded is
> non-deterministic. Ergo a recipe can depend on values being set for
> attributes in *any* cookbook but having values from one cookbook's
> attributes depend on values set in another's is essentially a dice roll.
> Therefore in this case (assume elsewhere we've required another cookbook's
> recipe where that cookbook's attributes file sets "apache" but it doesn't
> matter, cookbook attribute processing isn't ordered in anyway)
>
> passenger[:apache_load_path] =
> "#{apache[:dir]}/mods-available/passenger.load" if attribute?("apache")
>
> whether node[:passenger][:apache_load_path] ever gets set is a matter of
> luck; the "apache" attribute may or may not be set when this is being
> processed. However, if the cookbook needs information from another, it must
> access it in the recipe to rely on it being set. Is that right?

Yep.  That is why the solution may very well be include_attribute,
with similar semantics to recipes.  It lets us out of that trap.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com



Archive powered by MHonArc 2.6.16.

§