From time to time, rundeck adds a new line to framework.properties with a different UUID along with comments that the Server UUID was autocreated by Rundeck.
On the next Puppet run, the original file is recreated, triggering a service restart.
Unfortunately, I cannot tell what exactly triggers the write of the config file in rundeck. I restarted rundeck, logged in and looked at the config, but the framework.properties is unchanged.
But I see the below changes happening and saw a file as described after a --noop run that would have recreated framework.properties.
What are you seeing
On a VMWare VM /etc/frameworks.properties is generated with a line
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
on a VMWare VM...
From time to time, rundeck adds a new line to framework.properties with a different UUID along with comments that the Server UUID was autocreated by Rundeck. On the next Puppet run, the original file is recreated, triggering a service restart.
Unfortunately, I cannot tell what exactly triggers the write of the config file in rundeck. I restarted rundeck, logged in and looked at the config, but the framework.properties is unchanged. But I see the below changes happening and saw a file as described after a --noop run that would have recreated framework.properties.
What are you seeing
On a VMWare VM /etc/frameworks.properties is generated with a line
rundeck.server.uuid = VMware-42 19 5f 0b fd 14 94 b1-28 ## ## ## ## ## ## ##
which is the result of the fact 'serialnumber' on that host, used in rundeck::params:
What behaviour did you expect instead
A framework.properties should be created, that will not be changed by rundeck
Output log
Notice: /Stage[main]/Rundeck::Config::Global::Framework/File[/etc/rundeck/framework.properties]/content: content changed '{md5}c28d469bfcec60ae4bc928c1bb9af33c' to '{md5}a4744c761e153f1637193272ec540e92' Notice: /Stage[main]/Rundeck::Service/Service[rundeckd]: Triggered 'refresh' from 1 event
Any additional information you'd like to impart
Why can't we use fqdn_uuid($::fqdn) as default? I think this should always return a valid UUID?