-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When puppet manifest is applied without changes, {admin,apitoken}.aclpolicy may be regenerated triggering useless restart #149
Comments
I can confirm this happens. The ordering changes on each run. Let me take a look. |
The order changes due to the internal structure of hashes in ruby (?) but in general in other programming languages. Since access is through key and not through position, they can be positioned with any order and access through .each uses this ordering. You should check on erb template for aclpolicy and try to use something that dumps the aclpolicy always in the same order. |
What ruby version are you running? Ruby has maintained hash insertion order since 1.9. |
I'm using default ruby for RHEL 6.6 on the host where rundeck is deployed: ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] |
I suppose we could add a .sort call on the hash. |
Is this still an issue? |
I prepared my own module calling the puppet-rundeck one to setup in automated way instances of rundeck. I'm applying through puppet master and puppet agent is set to apply new configuration every 30 mins.
The issue i'm facing is very strange. No custom aclpolicy is defined in my own puppet module. Sometimes, when configuration is applied, on syslog i find messages regarding the change of the content of admin.aclpolicy or apitoken.aclpolicy. Since i'm doing file bucketing, with a check on file bucket and i find that there is a couple of rows swapped in the file, but the aclpolicy content is the same (checked with rd-acl).
When this files are regenerated, a restart of rundeck is triggered, which (in my case) could require few seconds of stop of the application.
This is maybe due to the way the array/hash of policies is flattened to file.
The text was updated successfully, but these errors were encountered: