subscribe is not restarting the service even though the file has changed :(

[Praveen Shivashankar]

Hi All,

 

I am managing the config files of a service through puppet. This config file is being created through 2 separate modules and concatenated together.  I am trying to modify the manifest in the module that installs the service so that whenever this config file changes (when the portion that comes from the 2nd module is concatenated to it), the service should restart.  I tried using the notify/subscribe parameter here, but the service does not restart even though the content of the file gets changed.

 

However, if I use the notify parameter on the second module by associating it with the service created by the first module, the service gets restarted.  I DO NOT want to do this way because it creates a dependency between these two modules which otherwise have been exclusive of one another.  Is there some way around this? The change in the config file content is happening only at the portion that is being modified by the second module.  But still, since I have used a subscribe parameter on the config, I believe that irrespective of which part of the file gets modified, the service must restart.

 

Does anybody have any idea if my understanding is correct or a way to work around this? Any help would be highly appreciated!!!

 

 

 service {"DE_${service_name}":
        enable          => true,
        ensure          => true,
        hasrestart      => true,
        hasstatus       => true,
        subscribe => File["${service_base_config_dir}/serverConfig.properties"]
        }

 

 

[jcbollinger]

On Thursday, July 19, 2012 4:29:53 AM UTC-5, Praveen Shivashankar wrote:

Hi All,

 

I am managing the config files of a service through puppet. This config file is being created through 2 separate modules and concatenated together.  I am trying to modify the manifest in the module that installs the service so that whenever this config file changes (when the portion that comes from the 2nd module is concatenated to it), the service should restart.  I tried using the notify/subscribe parameter here, but the service does not restart even though the content of the file gets changed.

 

However, if I use the notify parameter on the second module by associating it with the service created by the first module, the service gets restarted.  I DO NOT want to do this way because it creates a dependency between these two modules which otherwise have been exclusive of one another.

That doesn't make sense.  You have a dependency whether you subscribe in one direction or notify in the opposite direction.  The two modules cannot be exclusive.  Moreover, they should not be exclusive.  It doesn't make sense to manage a service and its config file independently of one another.

 

  Is there some way around this? The change in the config file content is happening only at the portion that is being modified by the second module.  But still, since I have used a subscribe parameter on the config, I believe that irrespective of which part of the file gets modified, the service must restart.

 

Does anybody have any idea if my understanding is correct or a way to work around this? Any help would be highly appreciated!!!

Puppet subscribe / notify relationships respond to changes in the Puppet resources on the precedent side (the target of the subscribe or the source of the notify).  It is possible -- but unwise -- to set things up so that those resources do not model all the properties of the physical resource that you want to respond to.  It sounds like that's probably what's happening here.
 

 

 service {"DE_${service_name}":
        enable          => true,
        ensure          => true,
        hasrestart      => true,
        hasstatus       => true,
        subscribe => File["${service_base_config_dir}/serverConfig.properties"]
        }

 

That setup will cause the service to be restarted if any of the properties managed via
File["${service_base_config_dir}/serverConfig.properties"] are changed, as determined by that resource.  If something else is done to the underlying file via another resource then the File knows nothing of it and will not broadcast an event.

You have left out the most important parts, which are the multiple declarations by which you manage file
${service_base_config_dir}/serverConfig.properties.  I can't give you specific advice without understanding what you're doing / trying to do.  In general, however, there are multiple possible approaches:

1. Combine the declarations managing your file into a single resource, and make your service subscribe to that.  That resource might be a File, an instance of a local defined type, or a resource from the Concat module, for instance.
2. Have your service subscribe to all resources managing parts of the file, instead of just one.  To do that, the value assigned to its 'subscribe' property should be an array of the needed resource references.
3. Use 'notify' going in the other direction, from each resource managing part of the file to the service it configures.

John

[Corey Hammerton]

What I have done with all my service resources is I declared the start, stop, restart and status parameters. I've never had a problem with subscriptions and notifications. 

[Praveen Shivashankar]

@John,

 

Thanks a lot for the detailed reply. I do concur with the idea that they cannot be mutually exclusive. But for some reason the client had that requirement. Fortunately I was able to convince them to let go of that, and now I just went ahead and pass the service name as an external parameter and using the notify can restart the service whenever the change in config file happens.