Stefan - obviously my example doesn't include classes but I see what you
mean. It is an interesting topic :-). So here was my example:
if !defined(Package["foo"]) {
package {"foo": ensure => installed }
}
Now if I wanted to define a specific revision, trigger or behaviour I could
understand why this would be problematic. For example:
if !defined(Package["foo"]) {
package {"foo":
ensure => "1.2.3",
notify => Exec["bar"],
}
}
Would be terrible - because I would lose the arguments if the package was
defined elsewhere earlier. That would be dumb. Also - the reverse is true
... by defining your own package you may be ruining someone else's package
definition which defines arguments. Like you say - the ordering can cause
problems.
FYI - The use-case where I would use the if !defined methodology would be
when you are defining a re-usable module that you know may (but not always)
conflict with another. Nothing is a silver bullet it seems in puppet, and I
have had to use this method at least once or twice to avoid stepping on
pre-existing content that I can't influence :-).
ken.
On Sunday, December 19, 2010 8:53:18 AM UTC, stefan.schulte wrote:
>
> On Sat, Dec 18, 2010 at 11:46:50AM -0800, Ken Barber wrote:
> > Can you elaborate?
> >
> > On Saturday, December 18, 2010 7:23:57 PM UTC, kc7zzv wrote:
> > >
> > >
> > > On Dec 18, 2010, at 3:50 AM, Ken Barber wrote:
> > >
> > > > For the record, an alternative that I don't believe was mentioned is
> to
> > > do something like:
> > > >
> > > > if !defined(Package["foo"]) {
> > > > package {"foo": ensure => installed }
> > > > }
> > >
> > > In general this is a bad idea though. Mostly because it can surprise
> you
> > > in bad ways.
> > >
> > >
>
> Its an ordering issue. Example
>
> node default {
> include foo
> if defined(Exec['uname']) {
> include bar
> }
> }
>
> class foo {
> exec { 'uname': command => '/usr/bin/uname' }
> notice("Class[foo] applied for defaultnode")
> }
> class bar {
> notice("Class[bar] applied for defaultnode")
> }
>
> This works but if you include foo after the ifstatement then bar will
> not be included. If you have a complex dependency chain the right order
> may not be as obvious as in this example (at least I dont know in which
> order puppet parses complex and nested class structures [and in my
> opinion I should not have to know it])
>
> -Stefan
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
