Puppet users - Jun 2013 - less drastic alternative to fail()?

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.

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.

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 <lavaman@gmail.com> 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.

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.