[chef] Re: RE: Re: RE: Re: LWRP inside LWRP Execution Question

[Daniel DeLeo < >]

On Tuesday, November 19, 2013 at 10:20 AM, Wes Parish wrote:

After more investigation, it looks like I am running into a problem with the multiple Chef run-time phases, compile and convergence. The fork idea has turned out to be bad because the resource run queue gets populated in the forked process and never makes it back to the parent.

I actually came across the same article earlier about the euid / egid wrt elevating privileges back to root (thus removing the need to fork). I have a prototype right now that works as long as all LWRP code executes during the compile phase using .run_action() (this is ugly and doesn't support notifications and isn't very Chef like).

I tried wrapping the execution as another user in a ruby_block, but it looks like Chef still pulls it apart and adds the resources to the run queue during compile, only to be executed as root during convergence.

Is there a construct that can hold multiple resources (I was hoping ruby_block worked this way) that lives in the resource run queue as an atomic unit so I can apply user-switch code before the other atomically-grouped-resources execute?

LWRPs with use_inline_resources do this, here’s the relevant code: https://github.com/opscode/chef/blob/master/lib/chef/provider/lwrp_base.rb#L40-70

You could maybe make your own LWRP that takes a block argument and use instance_eval inside the action block to provide a nested recipe. Resources inside that block won’t have visibility to the outside world, but the top-level LWRP could handle notifications correctly.

 

Thanks again for the help!

We

-- 

Daniel DeLeo