For the most part, execs is it, but sometimes you might use it for a
file or for a custom type.
I suppose that it could be built into each type as necessary with just
as much effectiveness.
In this case though, we might want to set up logging for the exec only
on specific failure states.
I.e. 2 is no logging but 1 is logging.
Trevor
On Wed, Jul 22, 2009 at 09:31, Nigel Kersten<nig...@google.com> wrote:
>
> On Wed, Jul 22, 2009 at 5:03 AM, Trevor Vaughan<peiriann...@gmail.com> wrote:
>>
>> I was thinking of this in a very fine grained way, such as a metaparameter.
>>
>> The situation that made me think of this is:
>>
>> class foo {
>> file { 'super/important':
>> ensure => 'file',
>> content => 'something great\n'
>> }
>>
>> exec { 'nice to have happen':
>> command => 'check stuff and set a file',
>> fail => 'soft'
>> }
>> }
>>
>> class bar {
>> require 'foo'
>>
>> # stuff that requires super/important file
>> }
>>
>> Basically, the exec in 'foo' is there because it's logical to place it
>> there, but some of it (the exec) just doesn't matter if it fails or
>> not.
>>
>> I see this being most relevant in the case of execs, but could apply
>> to some situations where everything might be a soft failure except for
>> a service starting.
>
> I was thinking about this the other day, that sometimes it would be
> useful to be able to specify that you don't care about the return code
> of an exec.
>
> Alternatively, being able to specify a list of acceptable return codes
> like [ 0, 1, 4] would also give us close to the same functionality as
> far as soft failures go with execs.
>
> I'm wracking my brains, and I really can't think of anything other
> than execs that I'd want this for personally.
>
>
>>
>> Trevor
>>
>> On Wed, Jul 22, 2009 at 02:38, Luke Kanies<l...@madstop.com> wrote:
>>>
>>> On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote:
>>>
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> This is going to be a great feature.
>>>>
>>>> Over time, I've been struggling with trying to keep things extremely
>>>> modular (perhaps too much so) but still well ordered.
>>>>
>>>> When I can make every class that needs apache just 'require apache', I
>>>> will be quite happy.
>>>>
>>>> However, I think that this means that if *anything* in the class
>>>> fails,
>>>> the dependent classes will fail too, is this correct?
>>>
>>> Yes, the dependent classes will be skipped if any resources in the
>>> required classes fail.
>>>
>>>>
>>>> Is there any way to make some things fail softly so that they can be
>>>> less hard than class-wise fatal?
>>>
>>> Hmm, no one's ever asked before.
>>>
>>> It seems reasonable that we could mark some resources as non-fatal,
>>> but what resources would you mark this way?
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Trevor
>>>>
>>>> On 07/21/2009 05:31 PM, James Turnbull wrote:
>>>>> Burkholder, Peter wrote:
>>>>>> I just finished listening to the Configuration Management panel from
>>>>>> OSBridge (on blip.tv).
>>>>>>
>>>>>> Near the end of it, Adam Jacob states that Puppet's resource
>>>>>> dependency
>>>>>> ordering is non-deterministic,
>>>>>> and that manifests that work fine 19 times will fail the 20th time.
>>>>>>
>>>>>> Is this true? I'm puzzled that what Luke considers one of Puppet's
>>>>>> strong suits is derided by
>>>>>> others as its Achille's heel.
>>>>>>
>>>>>
>>>>> There is a change in 0.25.0 that I also should have mentioned
>>>>> because it
>>>>> impacts this discussion.
>>>>>
>>>>> In 0.25.0 we've added a 'require' function. The doco is here:
>>>>>
>>>>> "Evaluate one or more classes, adding the required class as a
>>>>> dependency.
>>>>>
>>>>> The relationship metaparameters work well for specifying
>>>>> relationships
>>>>> between individual resources, but they can be clumsy for specifying
>>>>> relationships between classes. This function is a superset of the
>>>>> 'include' function, adding a class relationship so that the requiring
>>>>> class depends on the required class.
>>>>>
>>>>> .. Warning:: using require in place of include can lead to unwanted
>>>>> dependency cycles. For instance the following manifest, with
>>>>> 'require'
>>>>> instead of 'include' would produce a nasty dependence cycle, because
>>>>> notify imposes a before between File[/foo] and Service[foo]::
>>>>>
>>>>> class myservice {
>>>>> service { foo: ensure => running }
>>>>> }
>>>>>
>>>>> class otherstuff {
>>>>> include myservice
>>>>> file { '/foo': notify => Service[foo] }
>>>>> }
>>>>> "
>>>>>
>>>>> This takes some of the (potential) pain out of the ordering by
>>>>> allowing
>>>>> class level dependencies. This adds dependency resolution higher
>>>>> than
>>>>> between individual resources. It doesn't solve issues where you
>>>>> haven't
>>>>> built the right dependencies at a resource level but does provide
>>>>> more
>>>>> flexibility.
>>>>>
>>>>> This isn't the same as Chef - as Adam has pointed out Chef has top-
>>>>> down
>>>>> ordering rather than Puppet's dependency graph - but I think it'll
>>>>> make
>>>>> life easier for some people.
>>>>>
>>>>> Regards
>>>>>
>>>>> James Turnbull
>>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>>
>>>> iEYEARECAAYFAkpmXc4ACgkQyjMdFR1108BPnwCbBAYZ+kFWaKrORho1NOZK6+Ij
>>>> bNQAn2bb0SDw0aofNRH0wKf/fv5iDpzw
>>>> =eDIA
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> >
>>>
>>>
>>> --
>>> In our civilization, and under our republican form of government,
>>> intelligence is so highly honored that it is rewarded by exemption from
>>> the cares of office. --Ambrose Bierce
>>> ---------------------------------------------------------------------
>>> Luke Kanies | http://reductivelabs.com | http://madstop.com
>>>
>>>
>>> >
>>>
>>
>> >
>>
>
>
>
> --
> Nigel Kersten
> nig...@google.com
> System Administrator
> Google, Inc.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
