Ignore a failed dependency

[Bryan Traywick]

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.

Thanks for your help,

-- Bryan Traywick

[jcbollinger]

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

[jcbollinger]

On Friday, October 18, 2013 8:07:32 PM UTC-5, Bryan Traywick wrote:

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.

Puppet is not about commands, it is about resources and their state.  An application-order dependency expresses the concept that correctly applying resource B depends on resource A being in its intended target state.  Thus, it follows that resource A must be applied before resource B, and that if resource A is not applied successfully then resource B cannot be applied successfully, either.  Exec resources fit a bit loosely into this model, but they do fit, with two states: "not run" and "run".

On the other hand, if applying resource B successfully does not depend on the state of resource A, then the relative order in which they are applied does not matter.  You can provide an ordering relationship anyway, but doing so asserts a false dependency, and you have no room for complaint when Puppet behaves as if it were a true one.


John