cmd.wait can be used to create a command that only runs if a dependency triggers it. The key is now that the dependencies may only be injected like in the below template. Using cmd.run with onchanges_in would cause the command to always run if there isn’t any certificate in Pillar because there is no onchanges dependency in that case. Only once at least one certificate is present it starts working as expected.
With cmd.wait the command will never run unless it is explicitly triggered by watch respectively watch_in. Maybe I’m not aware of an alternative approach which would accomplish that short of including the command in the if clause of the Jinja template — which again would only work within the same file.
update-ca-certificates:
cmd.wait:
- name: /usr/sbin/update-ca-certificates
{% set cacerts = salt['pillar.get']('ca_certificates', None) %}
{% if cacerts %}
{% for cacert in cacerts.keys() %}
/usr/local/share/ca-certificates/{{cacert}}.crt:
file.managed:
- user: root
- group: root
- mode: '0664'
- contents_pillar: ca_certificates:{{cacert}}
- watch_in:
- cmd: update-ca-certificates
{% endfor %}
{% endif %}
If you move the cmd.wait state inside of the if statement, and use
{% set cacerts = salt['pillar.get']('ca_certificates', None) %}
{% if cacerts %}
{% for cacert in cacerts.keys() %}
/usr/local/share/ca-certificates/{{cacert}}.crt:
file.managed:
- user: root
- group: root
- mode: '0664'
- contents_pillar: ca_certificates:{{cacert}}
- onchanges_in:
- cmd: update-ca-certificates
{% endfor %}
update-ca-certificates:
cmd.run:
- name: /usr/sbin/update-ca-certificates
{% endif %}
Wouldn't this be the equivalent? You have already checked that there are certs, so you know there will be at least one file.managed...
Actually I had this covered in my original statement, @gtmanfred:
“[…] short of including the command in the if clause of the Jinja template — which again would only work within the same file.”
While I see that it would technically solve it for this specific implementation I don’t think it is a general solution.
ahh, i missed that. That is a decent point. Right now I am not aware of any active effort to deprecate cmd.wait.
@saltstack/team-core does anyone have a specific reason that we couldn't just get rid of the note about deprecating cmd.wait in the future from the docs?
Thanks,
Daniel
@Ch3LL Do you require any additional information from me?
Just to throw in my 2 cents here. I don't think it was necessary to deprecate cmd.wait. I understand that it can be confusing as the majority case would be covered with onchanges, but I don't see a need to cut it out of the codebase.
Yeah, I think we should just get rid of the note about deprecating it.
Agreed, the cmd.wait pattern is still a viable pattern and it seems still gives users flexibility beyond what they get with just onchanges
We haven't officially put it on a deprecation path, have we? I agree that it is still useful, we should keep it and not deprecate it. If that's what we decide to do, I think we can close this.
I have removed the note about cmd.wait being deprecated in #46338.
Most helpful comment
I have removed the note about
cmd.waitbeing deprecated in #46338.