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
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
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 -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.