subscribe and refreshonly - expected behavior

[Mike Reed]

Hello all,

My thanks in advance to anybody with thoughts on this.  I have a module in which I would like two resources to be applied/refreshed based on the change of their parent resource. 

The code looks something like this:

exec {'assume_default_domain':
      command     => "${pbis_bin_path}/config AssumeDefaultDomain true",
      subscribe   => Exec['create_home_dir'],
      refreshonly => true,
    }
   
    exec {'user_domain_prefix':
      command     => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
      subscribe   => Exec['assume_default_domain'],
    }

When running a 'puppet agent -tvd' I get the following:

Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 'refresh' from 1 events
Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling refresh of Exec[user_domain_prefix]
Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The container Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]/returns: executed successfully
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 'refresh' from 1 events
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container Class[Pbis::Config] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Stage[main] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my refresh event
Debug: Class[Pbis]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 25871380
Debug: Storing state
Debug: Stored state in 0.06 seconds

As you can see, the 'user_domain_prefix' resource is firing twice and I'm not sure why.  If I change the resource and add a 'refreshonly', I get the desired result (resource only being applied once):

exec {'user_domain_prefix':
      command     => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
      subscribe   => Exec['assume_default_domain'],
      refreshonly => true,

Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 'refresh' from 1 events
Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling refresh of Exec[user_domain_prefix]
Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The container Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 'refresh' from 1 events
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container Class[Pbis::Config] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Stage[main] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my refresh event
Debug: Class[Pbis]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 29272600
Debug: Storing state
Debug: Stored state in 0.06 seconds

My understanding is that 'subscribe' will both create a dependency and will require the refreshing of the dependent object, based on the subscribed objects' state.  I also understand 'refreshonly' to be a mechanism used when a dependent object is changed (sounds almost the same as subscribe except it doesn't create a dependency).  Based on my example above, I would expect 'subscribe' alone to satisfy my needs and I don't understand why I get duplicate refresh events when something is simply 'subscribed' but only one refresh event when a resource is set to both 'subscribe' and 'refreshonly'.

Would anybody have a quick explanation for this one?

Thanks again for your help in advance.

Cheers,

Mike

[jcbollinger]

On Wednesday, October 1, 2014 1:57:04 PM UTC-5, Mike Reed wrote:

Hello all,

My thanks in advance to anybody with thoughts on this.  I have a module in which I would like two resources to be applied/refreshed based on the change of their parent resource. 

The code looks something like this:

exec {'assume_default_domain':
      command     => "${pbis_bin_path}/config AssumeDefaultDomain true",
      subscribe   => Exec['create_home_dir'],
      refreshonly => true,
    }
   
    exec {'user_domain_prefix':
      command     => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
      subscribe   => Exec['assume_default_domain'],
    }

When running a 'puppet agent -tvd' I get the following:

[...]
 

As you can see, the 'user_domain_prefix' resource is firing twice and I'm not sure why.  If I change the resource and add a 'refreshonly', I get the desired result (resource only being applied once):

exec {'user_domain_prefix':
      command     => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
      subscribe   => Exec['assume_default_domain'],
      refreshonly => true,

[...]
 

My understanding is that 'subscribe' will both create a dependency and will require the refreshing of the dependent object, based on the subscribed objects' state.

To be clear: 'subscribe' does create an order-of-application dependency on the specified resource.  It also requests that the subscribing resource receive an 'event' if Puppet changes the state of the resource to which it subscribes.  If the subscribing resource is of a type that supports refreshing, then the effect of receiving one or more events is to schedule a refresh of the resource.

 

  I also understand 'refreshonly' to be a mechanism used when a dependent object is changed (sounds almost the same as subscribe except it doesn't create a dependency).

No, 'refreshonly' is not the same as subscribe at all, though the two can work together.  See below.

 

  Based on my example above, I would expect 'subscribe' alone to satisfy my needs and I don't understand why I get duplicate refresh events when something is simply 'subscribed' but only one refresh event when a resource is set to both 'subscribe' and 'refreshonly'.

Would anybody have a quick explanation for this one?

For resources that support refreshing (many don't), refreshing is a separate action from syncing.  For Execs, the refresh action is to run the Exec's command, unless you specify otherwise.  Normally, the sync action is also to run the command, but you can suppress the sync action altogether (that's what 'refreshonly' does).  Therefore, if an Exec is declared without refreshonly => true and without specifying a 'refresh' attribute, and if it receives an event from another resource (such as one to which it is 'subscribe'd) then its command will be run twice -- once for syncing, and once for refreshing.

Do be aware, too, that there is an historic family of bugs / unexpected behavior in play in this area, for which https://tickets.puppetlabs.com/browse/PUP-1106 is probably the best reference point.  That's not in play in the behavior you asked about, but you're nearby.


John

[Mike Reed]

Hey John,

Thank you for the info on this one.  I never even considered the sync and your answer provides some great insight.

Thanks again,

m.