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.
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 < " target="_blank"> > 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.