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


Chronological Thread 
  • From: Thom May < >
  • To:
  • Cc: Jonathan Matthews < >, Daniel DeLeo < >
  • 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:44:50 +0000

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.

§