Attribute ordering in nested Roles


#1

Hey all -

Is it intended (chef-client & -server 0.9.8 via RPMs) for a Role’s
defaults and overrides to be applied /before/ those of any Roles that
it itself includes in its run_list?

I’m seeing this behaviour whilst trying to dictate which httpd MPM I’d
like used. To my mind, it makes sense for a an (arbitrary) "App_XYZ"
Role to include an “httpd_server” Role (rather than merely apply them
in order, directly on the Node I’m interested in), but it requires
MPM:prefork. The fact that App_XYZ’s Attributes seem to be applied
before httpd_server’s means I can’t pull in everything that
httpd_server provides and then selectively override the MPM setting
from httpd_server’s default of MPM:worker.

Would it not be more sensible for the including Role’s defaults to
be applied first, then the defaults/overrides from the Roles it
includes, and finally the overrides from the including Role?

If I’ve missed something fundamental or a previous flamefest on this
issue, please do point me towards it and - if possible - an
explanation of how I should better achieve what I’ve described!

Cheers,
Jonathan

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


#2

Hello, Jonathan.

On Oct 5, 2010, at 7:00 AM, Jonathan Matthews wrote:

Is it intended (chef-client & -server 0.9.8 via RPMs) for a Role’s
defaults and overrides to be applied /before/ those of any Roles that
it itself includes in its run_list?

I have the same problem. I posted to this mailing list about it in June:
http://lists.opscode.com/sympa/arc/chef/2010-06/msg00013.html
I filed a bug as well, though I don’t have the link handy. There were no replies to the email, and no response to the bug report. :frowning:

  • R. Newbie

#3

On 5 October 2010 12:37, Ruby Newbie rubynewbie@me.com wrote:

On Oct 5, 2010, at 7:00 AM, Jonathan Matthews wrote:

Is it intended (chef-client & -server 0.9.8 via RPMs) for a Role’s
defaults and overrides to be applied /before/ those of any Roles that
it itself includes in its run_list?

I have the same problem. I posted to this mailing list about it in June:
http://lists.opscode.com/sympa/arc/chef/2010-06/msg00013.html
I filed a bug as well, though I don’t have the link handy. There were no replies to the email, and no response to the bug report. :frowning:

Thanks for that - appreciated. I can see from your bug
(http://tickets.opscode.com/browse/CHEF-1354) that there’s a solution
proposed in a duplicate bug
(http://tickets.opscode.com/browse/CHEF-1508) but there’s no
indication of if this is being actively pursued for 0.10. Could
anyone Opscode-ish comment?

Regards,
Jonathan

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


#4

On Tue, Oct 5, 2010 at 5:56 AM, Jonathan Matthews
contact@jpluscplusm.com wrote:

On 5 October 2010 12:37, Ruby Newbie rubynewbie@me.com wrote:

On Oct 5, 2010, at 7:00 AM, Jonathan Matthews wrote:

Thanks for that - appreciated. I can see from your bug
(http://tickets.opscode.com/browse/CHEF-1354) that there’s a solution
proposed in a duplicate bug
(http://tickets.opscode.com/browse/CHEF-1508) but there’s no
indication of if this is being actively pursued for 0.10. Could
anyone Opscode-ish comment?

Maybe I was too brief in my comment on CHEF-1508, but the situation is
that this change could potentially break people’s roles if they’re
relying on the current behavior (intentionally or otherwise) so it
can’t be changed until a major version bump, which means Chef 0.10.0.
We are still actively working on the major features that will be part
of the 0.10 release, so that’s why you don’t see any activity on the
ticket–I haven’t forgotten it, we just can’t merge it until we’re
ready to branch the code base for 0.10.

Regards,
Jonathan

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

Dan DeLeo


#5

On 5 October 2010 16:32, Daniel DeLeo dan@kallistec.com wrote

We are still actively working on the major features that will be part
of the 0.10 release, so that’s why you don’t see any activity on the
ticket–I haven’t forgotten it, we just can’t merge it until we’re
ready to branch the code base for 0.10.

Thanks for this, Dan.
FMI, is this fix definitely slated to hit 0.10.0, or might it be
0.10.x or even 0.11+?

Jonathan

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