Definition in a RubyBlock

Chef Infra (archive)
1

I need some guidance on how to call a definition from a ruby block.
Any help would be greatly appreciated.

–
Thanks,

Mark

2

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

3

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 sascha.bates@gmail.com 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

4

RiotGames build a cookbook for deploying artifacts from Nexus. There
are many amazing examples diagrams and documentation.

Take a look. [0] [1]

It is not possible (thankfully!) to call definitions from inside of a
Ruby Block without extension. I'd advise re-factoring your entire
solution to be LWRPs + wrapper cookbooks -- or go ahead and use Riot's
cookbook.

You mention specifically a few cases where an LWRP makes perfect sense
-- the YAML Control. File parsing, mapping each of them and calling
the definition, API calls -- all could be easily achieved with LWRP
actions with correct ordering (convergence time)

Cheers,

AJ

[0] http://community.opscode.com/cookbooks/artifact
[1] GitHub - RiotGamesCookbooks/artifact-cookbook: Provides your cookbooks with the Artifact Deploy LWRP

On 10 May 2013 09:52, Mark Pimentel markpimentel22@gmail.com 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 sascha.bates@gmail.com 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

5

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 <sascha.bates@gmail.com
mailto:sascha.bates@gmail.com> 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

6

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" danr@activestate.com 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 sascha.bates@gmail.comwrote:

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

7

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 markpimentel22@gmail.com 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" danr@activestate.com 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 sascha.bates@gmail.com
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