On Fri, Mar 18, 2011 at 12:17 PM, Alex Soto firstname.lastname@example.org 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
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:
- 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
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.
From: Leinartas, Michael MICHAEL.LEINARTAS@orbitz.com
To: email@example.com firstname.lastname@example.org
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?
http://tickets.opscode.com/browse/CHEF-1354 (linked from previous)
http://lists.opscode.com/sympa/arc/chef/2010-06/msg00013.html (linked from
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
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)