Will attribute merge ordering fix for nested roles be merged in 0.10.0?


#1

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.


#2

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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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.


#3

7 should win. I just ran into this problem this week. I solved it by
’demoting’ the base’s attribute to default and keeping the appserver’s
attribute as override - but that was very much a workaround to achieve the
desired (and expected) behavior.

  • Rob

On Thu, Mar 17, 2011 at 9:04 PM, Daniel DeLeo dan@kallistec.com 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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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.


#4

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 http://wiki.opscode.com/display/chef/Attributes#Attributes-SettingAttributes

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:

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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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.


#5

On Fri, Mar 18, 2011 at 12:17 PM, Alex Soto apsoto@gmail.com 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
http://wiki.opscode.com/display/chef/Attributes#Attributes-SettingAttributes
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:
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.

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

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.

Best wishes

Thanks,

Dan DeLeo

Forwarded message:

From: Leinartas, Michael MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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.


πόλλ’ οἶδ ἀλώπηξ, ἀλλ’ ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com


#6

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 :slight_smile:

Jonathan

On 18 March 2011 01:04, Daniel DeLeo dan@kallistec.com 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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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


#7

On 18 March 2011 01:13, Rob Guttman robguttman@gmail.com wrote:

7 should win. I just ran into this problem this week. I solved it by
’demoting’ the base’s attribute to default and keeping the appserver’s
attribute as override - but that was very much a workaround to achieve the
desired (and expected) behavior.

I’ve been using an annoying workaround which, none the less, will
allow me to automagically back itself out once the underlying
behaviour’s fixed.

Each Role, no matter how trivial, has an associated
"#{role.name}-ATTR" Role. All Attributes are assigned in Role-ATTR.
All Role inclusions are done by the main Role, which also includes
Role-ATTR in /last/ place in its runlist.

This fixes the attribute ordering problem, and will allow me to do a
global, scripted “move all attributes from -ATTR to $role and delete
$role-ATTR from $role’s runlist” once the underlying behaviour’s
fixed.

It looks complicated (which it isn’t) and annoying (which it is) but
it’s the only way I could see to fix the problem in a nested
Role-in-Role structure and then back the workaround out without much
manual work down the line.

Jonathan

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


#8

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
contact@jpluscplusm.com 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 :slight_smile:

Jonathan

On 18 March 2011 01:04, Daniel DeLeo dan@kallistec.com 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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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


#9

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
contact@jpluscplusm.com 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 :slight_smile:

Jonathan

On 18 March 2011 01:04, Daniel DeLeo dan@kallistec.com 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 MICHAEL.LEINARTAS@orbitz.com
To: chef-dev@lists.opscode.com chef-dev@lists.opscode.com
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