[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: delayed evaluation?

[Ranjib Dey < >]

i cant think of any standard docs, except i some blogs out there that recommended using it for temporary storage (the dude from nordstorm?) . I knew its there, but never used it. When i first encountered it in our code base (it was sumologic cookbook's sumo_source definition), i had changed it to an hwrp.

iirc node.run_state was used to detect loaded recipes (remember currently only recipes that are assigned via run list are present inside node.recipes not the ones which applied via included_recipe), there was some breaking changes during chef 10-> 11 migration too,

On Wed, Dec 18, 2013 at 4:48 PM, John Alberts < " target="_blank"> > wrote:

Thanks again to everyone for their input.  I think it's been decided beyond a shadow of a doubt that I should implement this in a custom provider. :)

A question to Ranjib's example; where can I find more information about node.run_state?  I only see mention of it regarding a windows provider and really no where else.

On Wed, Dec 18, 2013 at 4:40 PM, Sean OMeara < " target="_blank"> > wrote:

You want to implement this as an atomic operation from within a custom provider.

On Wed, Dec 18, 2013 at 7:10 PM, John Alberts < " target="_blank"> > wrote:

On Wed, Dec 18, 2013 at 10:17 AM, Dan Razzell < " target="_blank"> > wrote:

Isn't the issue only that %x[ls /tmp] is being evaluated at compile time?  Avoid that notation and you'll be able to do what you intend.  Use "system" instead and it will be evaluated as part of the ruby block.

I thought any ruby code inside a ruby block will not be evaluated during compile time and instead during the normal order of the execution phase.  I haven't tested this yet, but does it really matter if inside that ruby block I've used, %x[ls /tmp] or `ls /tmp` or system("ls /tmp") ?

--
John Alberts

--
John Alberts