[chef] Re: Re: Re: Re: Re: Chef 11 Attribute Changes -- Computed Attributes Edition

[Daniel DeLeo < >]

On Wednesday, November 7, 2012 at 9:46 AM, Jesse Campbell wrote:

I'm curious about this... Phil, can you give a more concrete example?

On Tue, Nov 6, 2012 at 9:19 PM, Phil Dibowitz < " target="_blank"> > wrote:

On Tue, Nov 06, 2012 at 06:12:43PM -0800, Daniel DeLeo wrote:
> In what cases do you use this behavior?
>
> And, in the case of defaults, you can go to normal or override attributes if you must. Do you find yourself frequently overriding role overrides in recipes?

All over the place... roles request stuff we want, and in certain cases we
determine based on the runtime environment that we can't do that.

But I shouldn't have to use override. Obviously I *can*, but it defeats the
whole purpose of the predecence hierarchy within a given precedence level.

Plus, as Adam would say, you have no runway. We went from a 14-level runway,
to a 2-level runway. Someone goes "override" in a role and you're fucked.

To be fair, we went from 11 to 9 de facto attribute precedence levels, or 7 if you exclude environments. But it's also the case that normal attributes can be less useful, since they persist to the node and you have to manually wipe them if you don't want them anymore, which leaves you with 6 "useful" levels of attributes.

 

I see no reason why recipes shouldn't win - we can accomplish everything
desired and still have the Attribute collapse such that recipes win.

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.

Another alternative is to add to the existing api, so you could do `node.recipe_default[:foo] = "bar"`

 

Runtime data should *always* win over static data.

There are quite a few ways to accomplish what you want given the code as it is now.

If what you really wanted in the first place was something like a runtime-evaluated role, you could implement that as a cookbook with all the logic you want in the attributes file.

Alternatively, you can use local variables instead of node attributes as the final input to your recipes. Your logic would be the same, and in the same place, you just assign the final value to a local instead.

If you really want the value to be set as a node attributes, you can simply go around the precedence system by accessing `node.attributes.role_override`.

Of these, dynamic-role-as-a-cookbook feels the most correct, but of course may not be appropriate for you.

 

--
Phil Dibowitz                             ">
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't matter
 and those who matter don't mind."
 - Dr. Seuss

-- 

Daniel DeLeo