On Friday, October 18, 2013 8:07:32 PM UTC-5, Bryan Traywick wrote:
>
> I have a general question and a specific question that are related.
>
> The general question: Is it possible to have the dependencies (commands
> that "require") of a command execute even if the command fails? Meaning
> create a sort of soft dependency where I would like the command to be
> performed but if it fails execute the things that depend on it anyway.
>
> Specifically: I have an 'Exec' that runs 'apt-get update'. Several
> commands 'require' this 'Exec' (e.g. ensuring that a package is installed).
> However, after an initial provisioning it's not absolutely necessary that
> 'apt-get update' gets run since those packages will be installed already.
> The 'apt-get update' is failing occasionally due to a slightly unreliable
> apt repo. I'd like all of the dependent tasks to execute after the 'apt-get
> update', but still execute even if it fails. Ideally I would like to be
> able to have an attribute on an 'Exec' (or really any puppet type) that
> says that it may fail and to just display a warning. As far as I can tell,
> such a attribute doesn't exist.
>
> My current thought is to set up a dummy Exec that just runs 'true', but
> have it notify another Exec that performs the real 'apt-get update'.
> Something like this (untested):
>
> exec { "apt-get update":
> command => "true",
> notify => Exec["real apt-get update"]
> }
>
> exec { "real apt-get update":
> command => "apt-get update"
> }
>
> Will this approach work in the way I intend? Commands that want a "soft"
> dependency on "apt-get update" will `require => Exec["apt-get update"]`
> which will always succeed but as a side effect perform the "real apt-get
> update" command. Will the `notify` cause "real apt-get update" to be
> performed during every deploy? And will the dependency/ordering graph be
> built such that "real apt-get update" gets executed before any of the other
> commands that `require => Exec["apt-get update"]`?
>
> This also brings up a third question that I thought of while formulating
> my thoughts for this question: Why are dependency and ordering linked in
> puppet? It seems to me that ideally there should be a way to specify that
> command A is performed before command B without making command B depend on
> command A. For example:
>
> exec { "apt-get update":
> command => "true"
> }
> exec { "real apt-get update":
> command => "apt-get update",
> before => Exec["apt-get update"]
> }
>
> I should be able to use "before" or "after" to specify ordering and
> "require" to specify dependence. If I'm missing something fundamental here
> about dependencies and ordering (or if I am fighting the paradigm) I'd
> appreciate the enlightenment.
>
>
Puppet will not apply a resource if it depends on another one that fails.
That is a necessary interpretation of "depends on". If the question even
arises then the solution is either:
1. The dependency is artificial, and can safely be removed, or
2. The dependency must not fail.
You evidently have a variation on (2). Your problem is that you are
characterizing the dependency wrongly: it is apparently not that "apt-get
update" must run before your resource; rather it is that an *attempt* must
be made to run that command first. There are at least two reasonably clear
ways to express that in Puppet:
exec { 'Attempt apt-get update':
command => '/path/to/apt-get update || /bin/true',
provider => 'shell'
}
OR
exec { 'Attempt apt-get update':
command => '/bin/true',
unless => '/path/to/apt-get update',
}
Either way, you don't need separate Execs.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
