gistfile1.md

I need to wait for a file (in this case /etc/hosts) to be updated. The current thought is that it may take up to 30mins for this file to be updated. Naturally, wait_for_event seemed the logical fit given the timeout` option.

With that said, i wanted to test out beacons and reactors to handle this. Seemed worthwhile. So i created a little test.

I've dropped a beacon on minion1 and have it watching modify on /etc/hosts. When I copy in a new hosts file on minion1, the beacon picks it up as expected and drops an event on the event bus. All is well there.

However, wait_for_event never sees the event. the orch run times out.

The interesting part is when i issue from minion1 the following:

salt-call event.send "salt/beacon/minion1/inotify//etc/hosts

the event comes across the bus and wait_for_event picks it up no issue. it continues on to the next block. I tried the same setup for the state runner. In this case, both the beacon and the event.send worked.

So, the event fails to be seen when using wait_for_event but seen with a state runner via beacon.

monitor-file.yml

test1:
  salt.function:
    - name: cmd.run
    - tgt: minion1
    - arg:
      - date
      
# This did not work below when using beacon
#test2:
#  salt.wait_for_event:
#    - name: salt/beacon/*/inotify//etc/hosts
#    - id_list:
#      - minion1
#    - timeout: 300
#    - require:
#      - salt: test1

# However, this did work below when using beacon
test2:
  salt.runner:
    - name: state.event
    - tagmatch: 'salt/beacon/minion1/inotify//etc/hosts'
    - count: 1
    - quiet: True
    - require:
      - salt: test1

test3:
  salt.function:
    - name: cmd.run
    - tgt: minion1
    - arg:
      - echo "--- hi ---"
    - require:
      - salt: test2