- From: Jonathan Matthews <
>
- To:
- Cc: Daniel DeLeo <
>
- Subject: [chef] Re: Fw: [[chef-dev]] Will attribute merge ordering fix for nested roles be merged in 0.10.0?
- Date: Fri, 18 Mar 2011 10:20:06 +0000
- Domainkey-signature: a=rsa-sha1; c=nofws; d=jpluscplusm.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CqRiy+V6VXPXXedhGRQCwXaJRM1dKZ7SlUy3SnRB0hxNimNmVSR2k3z8+CCO5mVTY1 t583usafkcmTscAlcQjEvaB8pfDQF/22k8YsgH3xwbnQfuKpTM1QQP90H+vpfhU2ArmH 1iqQVOLYcicL/Mkq8brvgT/fBxBWEi6488Rr4=
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.