- 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.