FAQ
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. 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?

Is that even desirable, or am I missing edge cases where that would break
things?

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Joe at Jun 12, 2013 at 1:15 am
    You can put the resources inside the class into a big if statement that
    checks the vars and does a notify if the class can't be applied.

    I've seen this in a few modules.
    On Tuesday, June 11, 2013 3:53:13 PM UTC-6, 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. 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?

    Is that even desirable, or am I missing edge cases where that would break
    things?
    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Trevor Vaughan at Jun 12, 2013 at 2:41 am
    Unfortunately, putting in a notify would not fail the class and skip
    dependencies, it would instead succeed.

    In general, you would want to use 'fail' to fail the compile since, in this
    case, you have a typo that you need to fix.

    However, I have also wanted a way for a soft-fail of some sort that would
    do what you are asking. In these cases, I tend to write custom types since
    this will do exactly what you are asking (at the expense of having to write
    the type).

    Trevor

    On Tue, Jun 11, 2013 at 9:15 PM, joe wrote:

    You can put the resources inside the class into a big if statement that
    checks the vars and does a notify if the class can't be applied.

    I've seen this in a few modules.

    On Tuesday, June 11, 2013 3:53:13 PM UTC-6, 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. 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?

    Is that even desirable, or am I missing edge cases where that would break
    things?
    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    Trevor Vaughan
    Vice President, Onyx Point, Inc
    (410) 541-6699
    tvaughan@onyxpoint.com

    -- This account not approved for unencrypted proprietary information --

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Jun 12, 2013 at 1:20 pm

    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+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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 11, '13 at 9:59p
activeJun 12, '13 at 1:20p
posts4
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase