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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7b5fa89c-53d8-4caf-9193-f2447442b2aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
