Salt: please document glob file watches

Created on 9 Jul 2014  路  18Comments  路  Source: saltstack/salt

Salt appears to support globs for file watches as per #663. However, I cannot seem to find any documentation other than that bug report. Could that please be documented somewhere?

Also, does the globbing support recursive watching instead of watching only one directory of files?

Documentation

Most helpful comment

Oh, that's a nifty feature! I'll include it with my other changset. Thanks for the ping!

All 18 comments

As in, will it support watching /foo/bar/baz with a watch: /foo/*? Just want to clarify.

And yes, we need to get this documented.

Well, yes, that. Maybe also document that it only seems to watch file objects that are defined in the same state file.

For example, if I include foo at the top of the bar.sls, any files managed in bar don't seem to affect objects in foo that have glob watches that look like they'd match such managed files.

Interesting, thanks for the update.

is there documentation for this already?

@wt Is the bug of included states not triggering watch still a thing? I'm pretty sure my globs work fine across multiple SLS files but haven't put a lot of effort into testing it.

I am still not seeing the expected behavior.

salt-call --version
salt-call 2014.7.1 (Helium)

/etc/sensu/conf.d:
  file.recurse:
    - source: salt://sensu/files/conf.d
    - template: jinja
    - require:
      - pkg: sensu
    - require_in:
      - service: sensu-server

sensu-server:
  service.running:
    - enable: True
    - require:
      - file: /etc/sensu/conf.d/redis.json
      - file: /etc/sensu/conf.d/rabbitmq.json
    - watch:
      - file: /etc/sensu/conf.d/*

----------
          ID: /etc/sensu/conf.d
    Function: file.recurse
      Result: True
     Comment: Recursively updated /etc/sensu/conf.d
     Started: 21:54:01.964245
    Duration: 592.775 ms
     Changes:
              ----------
              /etc/sensu/conf.d/checks.d/check_graphite.json:
                  ----------
                  diff:
                      New file
                  mode:
                      0644
----------
          ID: sensu-server
    Function: service.running
      Result: True
     Comment: Service sensu-server is already enabled, and is in the desired state
     Started: 21:54:02.681109
    Duration: 454.127 ms
     Changes:



Summary
-------------
Succeeded: 12 (changed=1)
Failed:     0
-------------
Total states run:     12

@srodrig0209 What if you change the watch to /etc/sensu/* or /etc/sensu/conf.d*? My impression is that it matches on state IDs, not file names - and you don't have any states with a slash after conf.d.

@anlutro Yep, that did it. /etc/sensu/conf.d* was all it took. Thanks!

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.

Can someone reopen this ticket? It's still undocumented...

Thank you for updating this issue. It is no longer marked as stale.

@MTecknology Wanna take a swing at this one, too?

Oh, that's a nifty feature! I'll include it with my other changset. Thanks for the ping!

Nearly three months later, I'm still fighting some sudden fires and my previous in-progress work is now quite stale. Unfortunately, I don't think my situation will change in the near future and I likely won't be able to get around to this. (Apologies to anyone that was waiting on me..)

On which branch should this PR go?

I thought to put it in doc/ref/states/requisites.rst.

@sathieu I would put it in the 2018.3 branch.

@rallytime Normally things should go to the oldest applicable branch, but since requisites.rst went through so many heavy changes, would it make more sense to apply this to develop?

@sathieu If you stick this in develop, do you think you could maybe take a shot at fixing the document linking? (requisite_any should be a link)

@sathieu If you stick this in develop, do you think you could maybe take a shot at fixing the document linking? (requisite_any should be a link)

This part is done in: #52019.

Was this page helpful?
0 / 5 - 0 ratings