Using notify with concat module...

[Sean]

Hello,

I was reading over several threads regarding the use of concat modules and subscribe capabilities.  It seems everyone is subscribe from another resource instead of notify with a concat resource.  My preference is to use notify, as I think it makes the code read better for documentation purposes.  One thread implied that subscribe and notify are interchangeable as long as refreshonly=true.  Is that correct in the case of using notify with concat?  Is it sufficient to use one notify statement inside the main concat resource for a file, or do I need to notify from each concat::fragment resource?  I am hoping someone can clear up a bit of confusion I've developed reading through the threads.  

For background, I'm using puppet to configure Gnome using dconf.  I've written a simple Exec resource that runs dconf-update, refreshonly => true.  A concat resource might manage a file that collects several Gnome options that relate to each other, where each concat::fragment resource corresponds to a single Gnome option...like a fragment for enabling the screensaver, and another fragment for the idle-delay.  If the file is updated, dconf-update needs to be run and should only be run once at the end of a puppet run.

Thanks for your thoughts.

[Luke Bigum]

On Monday, 23 January 2017 20:55:44 UTC, Sean wrote:

Hello,

I was reading over several threads regarding the use of concat modules and subscribe capabilities.  It seems everyone is subscribe from another resource instead of notify with a concat resource.  My preference is to use notify, as I think it makes the code read better for documentation purposes.  One thread implied that subscribe and notify are interchangeable as long as refreshonly=true.  Is that correct in the case of using notify with concat?  Is it sufficient to use one notify statement inside the main concat resource for a file, or do I need to notify from each concat::fragment resource?  I am hoping someone can clear up a bit of confusion I've developed reading through the threads.  

There should be no difference, the examples you've seen are probably written by someone with a mental model where 'subscribe' makes more sense, where you and I think 'notify' reads better.  The one time where it might get cumbersome is if you have one Concat resource that has to notify dozens of other resources, so the Notify parameter ends up being a large array of resources.  In that case the code might read better to put one Subscribe on each other resource, but that's personal preference.

I would not recommend you put your own requirements on concat::fragments, just let the Concat module sort out it's own dependencies. You can easily create loops, even through implicit relationships that aren't immediately obvious. For example here's two classes, one that manages the Gnome dconf file and one of my own that sets some of the settings I want, but I've decided I need dconf done first before the my_desktop class is finished:

*****************************************

$dconf_file = '/tmp/dconf'

class my_desktop {

  concat::fragment { 'setting1':

    target => $dconf_file,

  }

  service { 'some_stuff': }

}

class dconf {

  concat { $dconf_file: }

}

include dconf

include my_desktop

Class[dconf] -> Class[my_desktop]

*****************************************

That doesn't work so well.

[Sean]

Thank you for the reply!