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


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Thom May < >
  • Cc: , Jonathan Matthews < >
  • 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 10:46:42 -0700

Just merged this. Thanks everyone for your input.

-- 
Dan DeLeo

On Friday, March 18, 2011 at 3:44 AM, Thom May wrote:

I can't for the life of me remember why I wrote it that way round.
Appserver should definitely win.

On Fri, Mar 18, 2011 at 10:20, Jonathan Matthews
< "> > wrote:
Appserver wins, absolutely. Otherwise there's no sane way to mange
nested Roles in a "more specific Role includes more general Role" way.
Which I happen to use extensively :-)

Jonathan

On 18 March 2011 01:04, 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.

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.



--
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html




Archive powered by MHonArc 2.6.16.

§