On Wed, Nov 07, 2012 at 11:48:44AM -0800, Daniel DeLeo wrote:Mostly it comes down to the fact that attributes files are implemented via `instance_eval` on the node object, rather than having a defined DSL. I'd initially written this change so that attributes files would be evaluated in the context of a special DSL object, but we decided that this change needed more design and research so we had to drop it in the interest of shipping Chef 11.The only other obvious way to accomplish what you're asking for is to put the node object into "attribute-file-mode" or "recipe-mode", but this carries the risk that you get stuck in the wrong state. Given all the ways people use Chef's libraries to automate mangling of node data, it seems pretty likely that this would occur.But you keep track of them separately, right? So at read time, why can't youjust pick the same one you used to pick?
If what you really wanted in the first place was something like aruntime-evaluated role, you could implement that as a cookbook with all thelogic you want in the attributes file.No, because those aren't evaulated in run_list order. Our attributes filessetup all basic data-structures. Then our recipes all add/change/munge data ina sane way, based on runlist order: basic company-wide cookbooks, thencookbooks that apply to large swaths of servers, then cookbooks that are morespecific. Each one can change the data.We rely *heavily* on templates, so I all the early cookbooks setup thosetemplates, everyone has plenty of time to add to the data in recipes or rolesas necessary, and then the template will get the most appropriate data.
Alternatively, you can use local variables instead of node attributes as thefinal input to your recipes. Your logic would be the same, and in the sameplace, you just assign the final value to a local instead.No, because that's all compile-time. I need the templates to get the dataprovided by cookbooks that run after them.If you really want the value to be set as a node attributes, you can simplygo around the precedence system by accessing`node.attributes.role_override`.I could also do node.override, but that's silly. The precedence system waslogical before. Having data that is evaluated at *upload* time override datacomputed at *runtime* is counter-intuitive and limiting and defeats theoriginal beauty of the predence system.
--Phil Dibowitz ">Open Source software and tech docs Insanity Palace of Metallica"Be who you are and say what you feel, because those who mind don't matterand those who matter don't mind."- Dr. Seuss
Archive powered by MHonArc 2.6.16.