Re: Module runs but doesn't apply changes

[jcbollinger]

On Friday, August 24, 2012 5:32:57 AM UTC-5, Matthew Smith wrote:

Hi,

I've been looking at an odd issue, we have a module that I can prove is being loaded and run on both the agent and server end but no changes are being made.

I have validated that changes should have been applied and using notify I get alerts when it is run on the agent, but the file it should have created does not get created.
The puppet master was on 2.7.17 and agent on 2.7.18 so I have updated both to 2.7.19

The module that seems to not be working correctly is alfresco::cloud_alfresco, from the server debug you can see it has been loaded: (logs below)

debug: importing '/etc/puppet/modules/alfresco/manifests/cloud_alfresco.pp' in environment production
debug: Automatically imported alfresco::cloud_alfresco from alfresco/cloud_alfresco into production
debug: importing '/etc/puppet/modules/alfresco/manifests/cloud_params.pp' in environment production
debug: Automatically imported alfresco::cloud_params from alfresco/cloud_params into production
debug: Scope(Class[Alfresco::Cloud_alfresco]): Retrieving template alfresco/global/alfresco-global.properties
debug: template[/etc/puppet/modules/alfresco/templates/global/alfresco-global.properties]: Bound template variables for /etc/puppet/modules/alfresco/templates/global/alfresco-global.properties in 0.00 seconds
debug: template[/etc/puppet/modules/alfresco/templates/global/alfresco-global.properties]: Interpolated template /etc/puppet/modules/alfresco/templates/global/alfresco-global.properties in 0.05 seconds

And on the agent side: (more logs below)

Found the file: debug: /Stage[main]/Alfresco::Cloud_alfresco/File[/var/lib/tomcat6/shared/classes/alfresco-global.properties]/require: requires Class[Alfresco::Install]
Ran the file (but made no changes)
notice: after if else logic
notice: /Stage[main]/Alfresco::Cloud_alfresco/Notify[after if else logic]/message: defined 'message' as 'after if else logic'
debug: /Stage[main]/Alfresco::Cloud_alfresco/Notify[after if else logic]: The container Class[Alfresco::Cloud_alfresco] will propagate my refresh event
notice: Should Create File /var/lib/tomcat6/shared/classes/alfresco-global.properties
notice: /Stage[main]/Alfresco::Cloud_alfresco/Notify[Should Create File /var/lib/tomcat6/shared/classes/alfresco-global.properties]/message: defined 'message' as 'Should Create File /var/lib/tomcat6/shared/classes/alfresco-global.properties'
debug: /Stage[main]/Alfresco::Cloud_alfresco/Notify[Should Create File /var/lib/tomcat6/shared/classes/alfresco-global.properties]: The container Class[Alfresco::Cloud_alfresco] will propagate my refresh event
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: Service[mcollective](provider=redhat): Executing '/sbin/service mcollective status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig mcollective'
notice: Before if else logic
notice: /Stage[main]/Alfresco::Cloud_alfresco/Notify[Before if else logic]/message: defined 'message' as 'Before if else logic'
debug: /Stage[main]/Alfresco::Cloud_alfresco/Notify[Before if else logic]: The container Class[Alfresco::Cloud_alfresco] will propagate my refresh event

The section in the module that generates the debug output is as follows:

notify {"Before if else logic":}
  # If extra config set do concatinate
  if ($extra_config) {
    file {
      "${application_container_home}${application_container_instance}/shared/classes/alfresco-global.properties":
      content => template("${global_properties}","${extra_config}"),
      mode    => 0640,
    }
    notify {"Should Create File ${application_container_home}${application_container_instance}/shared/classes/alfresco-global.properties with extra config":}
  } else {
    file {
      "${application_container_home}${application_container_instance}/shared/classes/alfresco-global.properties":
      content => template("${global_properties}"),
      mode    => 0640,
    }
    notify {"Should Create File ${application_container_home}${application_container_instance}/shared/classes/alfresco-global.properties":}
  }
notify {"after if else logic":}

That code does not do quite what you might expect, on account of the fact that there are no resource relationships to enforce any particular order for applying the resources.  Inasmuch as you cut out some pieces of the fuller agent log, that log doesn't prove anything either.

You should set appropriate before / requires parameters on your resources to ensure an appropriate order of application.  Without them, the truncated log abstract proves nothing about whether the File resource was applied; it wouldn't need to have been between the Notify resources that are declared around it.


 

So regardless of the logic something should get pushed onto the OS called alfresco-global properties:
[root@opsalfrescon3 tomcat6]# updatedb
[root@opsalfrescon3 tomcat6]# locate alfresco-glo
[root@opsalfrescon3 tomcat6]#

Who knows whether the path containing your file may be excluded from the locate DB for one reason or another?  How about checking the actual expected path:

ls /var/lib/tomcat6/shared/classes/alfresco-global.properties

Indeed, if the manifests were working earlier in the day, then they must have applied the file then.  You wouldn't expect it to disappear from the server simply on account of Puppet ceasing to manage it, so it ought still to be there.

 

There are no errors generated to do with the template, this module was working earlier in the day and we had made some re-factors to it over the course of the day, but now it appears to be running it and not applying any configuration.

The agent log shows the File's 'require' parameter being honored, so the File appears in the catalog.  Are you sure it's not being applied?  How about grepping the agent's debug output for "alfresco-global.properties" to be sure you aren't overlooking the message.  Also, you could try tweaking your template (add a comment or something) to see whether the target node gets updated.

 

If anyone has any idea why this might be the help is appreciated

[...]

Agent debug log:

[...]
debug: /Stage[main]/Alfresco::Cloud_alfresco/File[/var/lib/tomcat6/shared/classes/alfresco-global.properties]/require: requires Class[Alfresco::Install]
< Abridged >
debug: /Stage[first]/Tomcat6::Install/File[/var/spool/abrt]/require: requires File[/var/cache/tomcat6/abrt]
debug: /Stage[first]/Tomcat6::Install/File[/var/cache/tomcat6/temp]/require: requires Package[tomcat6]
< Abridged >
debug: /Stage[first]/Tomcat6::Install/File[/var/cache/tomcat6]/require: requires Package[tomcat6]
debug: /Stage[main]/Mcollective::Install/File[/var/lib/puppet/ssl/mcollective_clients/opspuppet.alfresco.pri.pem]/require: requires File[/var/lib/puppet/ssl/mcollective_clients]

You appear to be missing relative ordering of your "first" stage with respect to your "main" stage.  That is unlikely to be related to your present issue, but it could cause you trouble in the future if you actually expect any relative order to be observed.

As to your issue, I'm not convinced you have one.  You may simply have been surprised by the order of resource application changing, so that the messages you were looking for in Puppet's log output were not where you were used to seeing them.  Such changes are likely whenever you modify your manifests, though they should not happen otherwise in relatively recent versions of Puppet.

 
John