subscribe => Package

[Frank]

Hi there,

I've defined a package array to install some software this way:

class install {

<…>

package { ['toola','toolb','toolc']:

  ensure => installed,

  require => Class['setup'],

  notify => Class['configure']

}

<….>

}

then under configure class I have something that is dependent of toola to install,

class configure {

file { '/etc/toola':

  content => "test"

}

}

Maybe I'm doing this notify/subscribe thing in the wrong way because sometimes Puppet tries the configure class first before install class. Even so…

<question>

Is there a way for me to force this dependency under file { '/etc/toola': subscribe => Package?

If yes, how can I define such a dependency with class Package after I've defined an package array without a specific name?

Cheers

-- 

Frank

[joe]

Instead of subscribe => Package, it's require => Package['toola'] or similar.

If you want to make sure all three packages are installed before the file, the best thing in this situation is to order the classes.

Either in a separate module altogether or somewhere that makes sense for you (perhaps the base class of this module), declare the classes in the order you need:

Class['install'] -> Class['configure']

This will make sure all resources in class install get applied before any resources in class configure.

[jcbollinger]

On Tuesday, November 27, 2012 1:05:48 PM UTC-6, joe wrote:

Instead of subscribe => Package, it's require => Package['toola'] or similar.

The OP does not use 'subscribe'.  He uses 'notify', and 'notify' provides a superset of the behavior of 'before'.  With the code he presented, he should not see Class['configure'] applied before any of Package['toola'], Package['toolb'], or Package['toolc'].  I would like to see a complete, minimal example that demonstrates the faulty behavior, as I suspect it is related to something not portrayed in the example given.
 

If you want to make sure all three packages are installed before the file, the best thing in this situation is to order the classes.

What he has written should work just fine.  Relationships to classes sometimes make sense and sometimes do not.  Among other things, they do not make sense for signaling relationships (expressed using 'notify' or 'subscribe', or the ~> or <~ operators).

On the other hand, I don't think signaling relationships involving classes are any more meaningful than ordinary ones, inasmuch as classes neither broadcast events nor have a refresh behavior.  File resources also have no refresh behavior, so there is really no point in using 'notify' instead of 'before' in the example.  Thus it could indeed work -- for that example -- to set up a relationship at class level.  I think there must be more to this story, though.

John

[Erik Dalén]

Actually, if you notify a class or define you will notify every resource contained inside it, causing services to be restarted and refresh only execs to be executed.

--
Erik Dalén

[jcbollinger]

On Tuesday, November 27, 2012 5:37:09 PM UTC-6, Erik Dalén wrote:

Actually, if you notify a class or define you will notify every resource contained inside it, causing services to be restarted and refresh only execs to be executed.

My bad.  Nevertheless, that's all the more reason why the OP's code ought to work, if that's all there is to it.


John