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!
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: chef - [chef] Attribute value precedence order in nested roles
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.
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: chef - [chef] Attribute value precedence order in nested roles
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.
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.
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+?
