On Tuesday, June 11, 2013 4:53:13 PM UTC-5, mpou...@afilias.info wrote:
>
> I have a few cases of error checking to make sure parameters supplied to
> my classes and defined types where the no-success option is to run the
> fail() function with a meaningful error. This seems to cause the entire
> agent run to fail as if the manifest couldn't be generated.
Yes. The fail() function injects a synthetic parse error into the catalog
compilation process.
> Does anyone know of an equivalent that would cause just that class to
> fail and stop processing (and obviously skip anything that depends on it)
> but allow the rest of the agent run to proceed as normal?
>
>
You should be able to declare
exec { "${name}-fail": command => '/bin/false' }
in the failure case. That Exec must always fail, therefore (I think) it
must cause any class declaring it to fail. To prevent other resources
declared by the same class from being applied, you will need also to set up
appropriate relationships inside the class.
> Is that even desirable, or am I missing edge cases where that would break
> things?
>
Actually, no, I don't think it's desirable. It's not so much about edge
cases as about the operational paradigm of Puppet. You make declarations
to the master about the target system's intended state, and you rely on the
agent to apply them. The failure scenarios are (1) your declarations don't
make sense, or (2) the agent failed to apply them. If one or more of your
declarations does not make sense, then that ought to undermine your
confidence in all the rest, therefore a catalog compilation failure is
appropriate. Conversely, if a declaration implies non-management of
certain resources by the agent, then the correct course is to avoid making
declarations about those resources when that condition is detected.
It is not sensible to make declarations to the master that you know the
agent must fail to apply. Puppet provides several flavors of conditionals
to assist you in tailoring your declarations to particular target nodes.
Use these as needed. If necessary, you can record the result of your class
parameter tests in a variable of that class, so that other classes can
refer to the result in their own conditional statements. If you find that
you have more than a few such tests, however, then your manifest set could
probably benefit from refactoring.
Note, too, that avoiding managing a particular resource is not at all the
same thing as managing it absent / disabled / etc.. It is often the case
that you don't really want to decide between making a declaration or not,
but rather between which of two or more alternative declarations to make.
For example, you might want to decide between "Apache is installed and
running" and "Apache is not installed". Just avoiding declaring the former
does not ensure the latter.
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
