Puppet users - Oct 2009 - How to handle failures of resources

Welcome all,

Resources  can  depend  one from each other, and failure of a required
resource prevent the dependants from being run.

But  how  to  trap these failures and handle them? Is there any way to
e.g.   set  a  variable  $error_happened  to  "true"  if  some promise
about  the  resource  couldn''t  be  kept? Maybe even there is a way to
capture the error string?

Some  preventive  actions  can  be automated, and Puppet seems to be a
good  place to implement   them.   And   users  who program Puppet are
encouraged to keep from external scripts as far as they could.

--
Thank you for your reply,
 Adam Ryczkowski


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 18, 2009, at 2:15 AM, Adam Ryczkowski wrote:
>
> Welcome all,
>
> Resources  can  depend  one from each other, and failure of a required
> resource prevent the dependants from being run.
>
> But  how  to  trap these failures and handle them? Is there any way to
> e.g.   set  a  variable  $error_happened  to  "true"  if  some
promise
> about  the  resource  couldn''t  be  kept? Maybe even there is a
way to
> capture the error string?
>
> Some  preventive  actions  can  be automated, and Puppet seems to be a
> good  place to implement   them.   And   users  who program Puppet are
> encouraged to keep from external scripts as far as they could.
What are your goals here?

There isn''t a lot of room for programming these aspects of Puppet from
within the language, but you''re the first person to ask for this kind  
of feature, so for all I know, what you''re asking for might be  
straightforward to add.

-- 
A conservative is a man who believes that nothing should be done for
the first time. --Alfred E. Wiggam
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

>> Welcome all,
>>
>> Resources  can  depend  one from each other, and failure of a required
>> resource prevent the dependants from being run.
>>
>> But  how  to  trap these failures and handle them? Is there any way to
>> e.g.   set  a  variable  $error_happened  to  "true"  if 
some promise
>> about  the  resource  couldn''t  be  kept? Maybe even there is
a way to
>> capture the error string?
>>
>> Some  preventive  actions  can  be automated, and Puppet seems to be a
>> good  place to implement   them.   And   users  who program Puppet are
>> encouraged to keep from external scripts as far as they could.
> What are your goals here?
> There isn''t a lot of room for programming these aspects of Puppet
from
> within the language, but you''re the first person to ask for this
kind
> of feature, so for all I know, what you''re asking for might be
> straightforward to add.
This  question  is  connected  with  my  previous  one,  the one about
determining  if  there  is  enough  place in the destination to copy a
file.  Because  if there isn''t - the "file" resource fails
and I could
catch  that  condition  and  do  some  action  -  rollback  whole move
operation,  which  means delete the ".puppettmp" file, move back those
files, which had been already moved, and perhaps send an email.

Now  I  understand, that whole that process would better be handled by
custom  scripts, so maybe indeed there is no need for such feature. At
least not when transaction support is ready.

--
 Adam Ryczkowski
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I wouldn''t mind having failure detection.

Say somehow a bad copy of a .conf file is distributed; and the service
fails to start.
If that can be detected and used as a condition, puppet could than
call up another manifest to drop in a default/backup copy of the .conf
file and restart the service almost immediately.
Toss in a notify function on that manifest, and it would be a very
handy feature for making changes on diverse production systems.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 19, 2009, at 7:56 AM, LdvT wrote:
>
> I wouldn''t mind having failure detection.
>
> Say somehow a bad copy of a .conf file is distributed; and the service
> fails to start.
> If that can be detected and used as a condition, puppet could than
> call up another manifest to drop in a default/backup copy of the .conf
> file and restart the service almost immediately.
> Toss in a notify function on that manifest, and it would be a very
> handy feature for making changes on diverse production systems.
My goal has always been to support this, but I''ve never quite gotten  
there, and it''s never seemed to matter enough to people that.

At the least, you need every resource to be reversible (including  
execs), and you need a more consistent internal event log than we  
currently maintain, but I think ordering issues become really  
complicated too -- if you installed a package then started a service,  
you have to do them in the inverse order, but if you modified a file  
and restarted the service then you have to do them in the same order.

Basically, you need a much richer language for talking about  
dependencies, and I think that''s the real complexity.

-- 
Risk! Risk anything! Care no more for the opinions of others, for those
voices. Do the hardest thing on earth for you. Act for yourself. Face
the truth. -- Katherine Mansfield
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 20, 11:59 pm, Luke Kanies <l...@madstop.com>
wrote:
> On Oct 19, 2009, at 7:56 AM, LdvT wrote:
>
>
>
> > I wouldn''t mind having failure detection.
>
> > Say somehow a bad copy of a .conf file is distributed; and the service
> > fails to start.
> > If that can be detected and used as a condition, puppet could than
> > call up another manifest to drop in a default/backup copy of the .conf
> > file and restart the service almost immediately.
> > Toss in a notify function on that manifest, and it would be a very
> > handy feature for making changes on diverse production systems.
>
> My goal has always been to support this, but I''ve never quite
gotten  
> there, and it''s never seemed to matter enough to people that.
>
> At the least, you need every resource to be reversible (including  
> execs), and you need a more consistent internal event log than we  
> currently maintain, but I think ordering issues become really  
> complicated too -- if you installed a package then started a service,  
> you have to do them in the inverse order, but if you modified a file  
> and restarted the service then you have to do them in the same order.
>
> Basically, you need a much richer language for talking about  
> dependencies, and I think that''s the real complexity.
>
> --
> Risk! Risk anything! Care no more for the opinions of others, for those
> voices. Do the hardest thing on earth for you. Act for yourself. Face
> the truth. -- Katherine Mansfield
> ---------------------------------------------------------------------
> Luke Kanies |http://reductivelabs.com|http://madstop.com
As nice as it might be to have completely reversible resources, I
don''t think we need quite that much.
Instead, I would like something like the notify parameter, but
specifically triggered on failure only.
i.e.:

exec {"generic install"
    command => "mkdir -p /opt/program ; tar -xzf /tmp/program-
$kernel.tar.gz -C /opt/program",
    creates => "/opt/program",
    onfail => Exec["opps"],
}

exec => { "opps":
   command => "rm -rf /opt/program",
   refreshonly => true,
}

Basically, just making it easy to create and call custom undo scripts
or functions.
Even though the creates paramater is bad, the exec would try again
next run because /opt/program gets removed on failure.
And than "opps" will only run after a failure of "generic
install".
With the way notify works, an undo could start triggering other
resources as well; although the potential undo-redo cycle might be
problematic.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Oct 22, 2009, at 9:50 AM, LdvT wrote:
>
> On Oct 20, 11:59 pm, Luke Kanies <l...@madstop.com> wrote:
>> On Oct 19, 2009, at 7:56 AM, LdvT wrote:
>>
>>
>>
>>> I wouldn''t mind having failure detection.
>>
>>> Say somehow a bad copy of a .conf file is distributed; and the  
>>> service
>>> fails to start.
>>> If that can be detected and used as a condition, puppet could than
>>> call up another manifest to drop in a default/backup copy of  
>>> the .conf
>>> file and restart the service almost immediately.
>>> Toss in a notify function on that manifest, and it would be a very
>>> handy feature for making changes on diverse production systems.
>>
>> My goal has always been to support this, but I''ve never quite
gotten
>> there, and it''s never seemed to matter enough to people that.
>>
>> At the least, you need every resource to be reversible (including
>> execs), and you need a more consistent internal event log than we
>> currently maintain, but I think ordering issues become really
>> complicated too -- if you installed a package then started a service,
>> you have to do them in the inverse order, but if you modified a file
>> and restarted the service then you have to do them in the same order.
>>
>> Basically, you need a much richer language for talking about
>> dependencies, and I think that''s the real complexity.
>>
>> --
>> Risk! Risk anything! Care no more for the opinions of others, for  
>> those
>> voices. Do the hardest thing on earth for you. Act for yourself. Face
>> the truth. -- Katherine Mansfield
>> ---------------------------------------------------------------------
>> Luke Kanies |http://reductivelabs.com|http://madstop.com
>
> As nice as it might be to have completely reversible resources, I
> don''t think we need quite that much.
> Instead, I would like something like the notify parameter, but
> specifically triggered on failure only.
> i.e.:
>
> exec {"generic install"
>    command => "mkdir -p /opt/program ; tar -xzf /tmp/program-
> $kernel.tar.gz -C /opt/program",
>    creates => "/opt/program",
>    onfail => Exec["opps"],
> }
>
> exec => { "opps":
>   command => "rm -rf /opt/program",
>   refreshonly => true,
> }
>
> Basically, just making it easy to create and call custom undo scripts
> or functions.
> Even though the creates paramater is bad, the exec would try again
> next run because /opt/program gets removed on failure.
> And than "opps" will only run after a failure of "generic
install".
> With the way notify works, an undo could start triggering other
> resources as well; although the potential undo-redo cycle might be
> problematic.
Ah; another interesting approach.

Unfortunately our event system isn''t quite flexible enough to handle  
it.  We''re revamping it for rowlf, so it should be extensible enough  
to support it after that.  Can you enter that as a feature request?

-- 
A person''s maturity consists in having found again the seriousness one
had as a child, at play. --Friedrich Nietzsche
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---