-----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?
Is there any way to make some things fail softly so that they can be
less hard than class-wise fatal?
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-----
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
