[chef] Re: Re: Re: Re: Re: Definition in a RubyBlock


Chronological Thread 
  • From: AJ Christensen < >
  • To: chef < >
  • Subject: [chef] Re: Re: Re: Re: Re: Definition in a RubyBlock
  • Date: Fri, 10 May 2013 10:57:30 +1200

You can use the LWRP inline resources compilation mode to allow the
correct propagation of notifications from independent resources
embedded within LWRP action blocks.

"If any embedded resources have been updated, the top-level
lightweight resource is marked as updated, and any notifications set
on it will be triggered normally."

This was recently added, chef11 specific. [0]

Cheers,

AJ

[0] 
http://docs.opscode.com/breaking_changes_chef_11.html#inline-compile-mode-for-lightweight-resources

On 10 May 2013 10:53, Mark Pimentel 
< >
 wrote:
> Yes the response file is my trigger for a new deployment of the artifact.
> That deployment would consist of a download, extract, and a permissions.
> This sequence was all triggered via notifications hence the use of the
> definition as opposed to lwrps.  I took a look at the artifact_deploy
> cookbook and I may be able to implement that.  But I do agree with your
> statement about the lwrps and the data they return.
>
> On 2013-05-09 6:28 PM, "Dan Razzell" 
> < >
>  wrote:
>>
>> Hi Mark,
>>
>> I'd echo AJ's suggestion about moving the functionality into LWRPs.
>> They're not hard to set up, and this approach gives you complete expression
>> within Ruby, taking place at convergence time.
>>
>> One frustration I have with Chef (others are free to concur or explain how
>> to get past it) is that there isn't a very rich transfer of information 
>> back
>> from a resource when it converges.  You can pass attribute values in to the
>> resource but you basically get to transfer just two bits back: either
>> success or failure, or a change to the resource which can be used to 
>> trigger
>> a notify action.  (Or you can throw an exception, but then you can't 
>> specify
>> where to catch it, so it's not really usable as a means of flow control.)
>>
>> What this means in terms of algorithm design is that once you're working
>> within an LWRP, you try to complete the task there as much as possible.  If
>> your main concern is to manage some API calls, that's easy.  It gets a bit
>> trickier if you then want to conditionally trigger other resources within a
>> Chef recipe depending on what comes back from those calls, but if you can
>> reduce that to one or two bits of information then it's possible.
>>
>> Is your templated response file serving as a channel to communicate
>> additional information between Chef resources?  It seems like you only care
>> whether or not it's changed, which is one bit.  In that case, it might be
>> more elegant to use notifications instead.
>>
>> Cheers,
>> Dan
>>
>> On 13-05-09 02:52 PM, Mark Pimentel wrote:
>>
>> I actually like to get ideas from people as they may provide insight to
>> tackling a problem in such a way I may not have considered.  So your
>> response is appreciated.
>>
>> I have a recipe that deploys these artifacts from a nexus repo. They are
>> simple archives and are controlled by a yaml file that I ship with the
>> cookbook.  I have a definition that I call for each one of these artifacts
>> that are to be deployed.
>>
>> Currently, I parse that yaml control file then make iterative calls to the
>> nexus repo for the artifact information.  Then I make a descision as to
>> whether I need to deploy the artifact, or update it if it is newer than the
>> one I have.  This is controlled by dumping the nexus api call to a 
>> templated
>> response file.  If the templated response file changes, that triggers other
>> resources in the definition to act, which is to deploy the artifact.  That
>> is the definition.
>>
>> Now, the reason I want to have this definition embedded into a ruby block
>> is to control the execution of those api calls.  Currently they fire 
>> because
>> I parse the yaml control file and iterate over each entry calling the
>> definition.  This occurs in pure ruby, which I know is called inline with
>> the compile phase.  I wanted to push this into the ruby block to have it
>> called in the convergence phase instead.
>>
>> Hope that sheds light on my problem.  And once again thank you for your
>> response and interest.
>>
>>
>> On Thu, May 9, 2013 at 5:11 PM, Sascha Bates 
>> < >
>> wrote:
>>>
>>> Hi Mark,
>>>
>>> Let me just say that, when I ask for help and get back someone telling me
>>> to do what I want a different way, it really annoys me. So feel free to 
>>> tell
>>> me to shove off, BUT, with that said....
>>>
>>> Can you share what you're trying to accomplish and maybe we can help you
>>> get there without trying to embed one resource block within another, which
>>> is really what you're talking about doing?
>>>
>>> Sascha
>>>
>>>
>>> Mark Pimentel wrote:
>>>
>>>
>>> I need some guidance on how to call a definition from a ruby block.
>>> Any help would be greatly appreciated.
>>>
>>> --
>>> Thanks,
>>>
>>> Mark
>>
>>
>>
>>
>> --
>> Thanks,
>>
>> Mark



Archive powered by MHonArc 2.6.16.

§