[chef] Re: Re: Fw: [[chef-dev]] Will attribute merge ordering fix for nested roles be merged in 0.10.0?


Chronological Thread 
  • From: Hedge Hog < >
  • To:
  • Subject: [chef] Re: Re: Fw: [[chef-dev]] Will attribute merge ordering fix for nested roles be merged in 0.10.0?
  • Date: Fri, 18 Mar 2011 12:33:47 +1100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oyAyf2/+gk1cw7e2QJA0ndiJnu49HVhDvxJnGSt76G5ZtxNMD0WGktz0YXi2HYeRUM 7Aw5SsB+8+1DvkgwTilO+dH09DLHsYw+qlk2x46IgZ18wEYft64B+2xjX3APeJ4YmduI QFSOFKlY4PKl/Jlg4OrFNV6KAD3CB6SqEBPSY=

On Fri, Mar 18, 2011 at 12:17 PM, Alex Soto 
< >
 wrote:
> Assuming the attributes are at the same precedence level I would want/expect
> appserver role to 'win'.  There is an implied precedence of appserver being
> higher than base by the containment.   It does put a wrinkle in the
> attributes precendence table on the wiki
>  <http://wiki.opscode.com/display/chef/Attributes#Attributes-SettingAttributes>
> On Mar 17, 2011, at 6:04 PM, Daniel DeLeo wrote:
>
> Forwarding this to the primary list so everyone can chime in. I don't have a
> strong opinion either way, but I would like to ensure there is strong
> support for changing the current behavior before going ahead with this.
> To summarize the issue for those unfamiliar:
> Given:
> * A role "base"
> * A role "appserver" that includes role "base"
> When both roles set an attribute, which one should "win"? E.g., if both
> "base" and "appserver" define an attribute "logrotate_days", but you have:
> * base: logrotate_days => 5
> * appserver: logrotate_days => 7
> What should be the value of logrotate days when a node has the "appserver"
> role? The current behavior is that "base" wins, so logrotate_days would be
> 5, because it is included last. The bug report asserts that the behavior
> should be the opposite.
>

Appserver should win.  Rationale:
I think there may be a tendency to think of Appserver as a sub class
of Base, so POLS holds you'd expect (instance) level data in Appserver
to override Base.
Similarly if you think of Base as an included module (Included at the
top of a class def), you'd still expect Appserver's data attributes to
win.

It is only if you think of Base being included at the end of a class
def that you'd expect it's attributes/settings/data to win.
OR, if you view these as two orthogonal items in a list - in which
case the last seen wins.
For that last-seen-in-list behavior to make sense, you'd have stop
referring to any inheritance ideas/relationship between Base and
Appserver, as soon as you do that most people mindset is likely to
shift in the way I described above.

Apologies for the long response, but that Base would ever win over
Appserver is very surprising to me.

Best wishes

> Thanks,
> --
> Dan DeLeo
>
> Forwarded message:
>
> From: Leinartas, Michael 
> < >
> To: 
> 
>  
> < >
> Date: Thursday, March 17, 2011 10:05:16 AM
> Subject: [[chef-dev]] Will attribute merge ordering fix for nested roles be
> merged in 0.10.0?
>
> Some background:
> http://tickets.opscode.com/browse/CHEF-1508
> http://tickets.opscode.com/browse/CHEF-1354 (linked from previous)
> http://lists.opscode.com/sympa/arc/chef/2010-06/msg00013.html (linked from
> previous)
> The last link has a good summary of use case at the top.  Last update was
> that this was potentially a breaking change and so had to wait until 0.10.0
> to be considered.  I'm wondering if there's been any discussion on including
> it.  I personally feel that the current behavior is very unintuitive and
> generally undesirable, but perhaps there are use cases I haven't
> considered.
> FWIW I've been running my chef clients with this patch from 0.9.8 through
> 0.9.14 without issue.
>
>



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com



Archive powered by MHonArc 2.6.16.

§