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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
