Hello all,
I have two cron.env_present states as follows:
cron_mail_admin:
cron.env_present:
- user: root
- name: MAILTO
- value: [email protected]
cron_char_set:
cron.env_present:
- user: root
- name: CONTENT_TYPE
- value: "text/plain;charset=utf-8"
now, the second one (CONTENT_TYPE) is always reported as changed on highstate:
# salt-call state.highstate
[...]
local:
----------
ID: cron_char_set
Function: cron.env_present
Name: CONTENT_TYPE
Result: True
Comment: Cron env CONTENT_TYPE updated
Started: 14:50:00.224036
Duration: 637.356 ms
Changes:
----------
root:
CONTENT_TYPE
Summary
------------
Succeeded: 1 (changed=1)
Failed: 0
------------
Total states run: 1
This happens on every run. It doesn't seem to be related to the "strange" value of CONTENT_TYPE, and it has been like this on 2014.7.2, too.
The crontab looks like this:
# Lines below here are managed by Salt, do not edit
[email protected]
CONTENT_TYPE=text/plain;charset=utf-8
# SALT_CRON_IDENTIFIER:cron_run_salt
51 7 * * * /root/bin/run-salt '/bin/true'
(before and after running highstate).
Regards,
Torsten
Interesting. I'm guessing we're not properly detecting the entry at the beginning of the state if it's already present, and so we're "adding" it every time and reporting changes. Anyway, we'll investigate this.
I'm guessing it has to do with the quotes because I see the same behavior with:
cron_mail_admin:
cron.env_present:
- user: myuser
- name: MAILTO
- value: ""
Just a note that I'm running Carbon and face basically the same problem, except it's not an empty string that causes it, but an integer value, like so:
cron_foo:
cron.env_present:
- name: FOO
- value: 1
Forcing the value to a string did solve it for me.
Possibly related - with cron.present, I was able to reproduce the original issue without using special or identifier - in my YAML, if the value of commented is a quoted string of True (literally "True") instead of plain True (True), it triggers the same behavior. Strangely, in my state file with two cron.present entires, only one is affected (and it's always the same one).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
Most helpful comment
Just a note that I'm running Carbon and face basically the same problem, except it's not an empty string that causes it, but an integer value, like so:
Forcing the value to a string did solve it for me.