using multiple EXECs

[bapi...@cloudwick.com]

Hi all,

 I am building this module which has rpm packages in it and execs commands.

What is the best way to build this module.. does writing numerous execs is a good way to start with??

Im finding my way to work with puppet ... any help is greatly appreciated!! :)

Thank You 

[Rob Nelson]

Puppet does not know what happens in an Exec resource, so it has one foot in and one foot outside of the graph and impairs puppet's ability to define state consistently and enforce idempotency. Because of these, Execs are the least desirable resource type. Think of them as a "break in case of emergency" type resource. Only use them if no other resource will work.

Some alternatives might include:

* Repackage the RPMs to include appropriate post-install scripts, so there is nothing to exec afterward

* Use the correct resource types to achieve the same goal. If the command would modify some file, use a File resource to manage the file's permissions, contents, etc. via puppet.

* If you have multiple commands to run and there is absolutely no way to use other puppet resource types to obtain the same results, then create a script that is pushed down as a Package or File resource, then Exec that file. File+Exec is usually better than a bunch of individual Execs, for both better modeling of state, and your sanity (esp when dealing with escaped strings, any sort of logic between Execs, and to have a logical view of what the Execs are doing).

Again, Execs should generally be your last resort. Find another way when possible!

Rob Nelson
rnel...@gmail.com

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8d95be4c-d2bb-44c0-913e-5dc96cf0f033%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Friday, April 22, 2016 at 7:15:52 AM UTC-5, Rob Nelson wrote:

Puppet does not know what happens in an Exec resource, so it has one foot in and one foot outside of the graph and impairs puppet's ability to define state consistently and enforce idempotency. Because of these, Execs are the least desirable resource type. Think of them as a "break in case of emergency" type resource. Only use them if no other resource will work.

And if you do use them, then do so in a manner that is consistent with Puppet's resource model.  The 'creates', 'onlyif', and 'unless' parameters provide the means for an Exec to determine whether it is already in sync, and they should be used whenever the default behavior (that the Exec always is intially out of sync) is unsuitable.  Additionally, in most cases it is best for an Exec that is not refreshonly to have trivial refresh behavior, i.e. refresh => '/bin/true'.  Under no circumstances should an Exec modify any physical resource that is managed separately by Puppet.

 

Some alternatives might include:

* Repackage the RPMs to include appropriate post-install scripts, so there is nothing to exec afterward

* Use the correct resource types to achieve the same goal. If the command would modify some file, use a File resource to manage the file's permissions, contents, etc. via puppet.

* If you have multiple commands to run and there is absolutely no way to use other puppet resource types to obtain the same results, then create a script that is pushed down as a Package or File resource, then Exec that file. File+Exec is usually better than a bunch of individual Execs, for both better modeling of state, and your sanity (esp when dealing with escaped strings, any sort of logic between Execs, and to have a logical view of what the Execs are doing).

Don't forget

* Write a proper custom type and provider to use in place of the Exec(s).

John

[bapi...@cloudwick.com]

thanks for the help guys!!!