Salt: Watching a directory tree using file.recurse fails

[shahn]

In service.running, I'm using - watch: with - file /etc/package. /etc/package is using file.recurse to copy a tree over. When I make a change to one of the files on the salt master and run highstate, the new file is copied in place correctly but the service is not restarted.

Note that using watch: - file /etc/package/* gives the error "The following requisites were not found".

[jfindlay]

@shahn, will you provide the output of salt --versions-report? Thanks.

[shahn]

Of course:

The minion is on debian jessie:

$ salt-minion --versions-report
           Salt: 2014.1.13
         Python: 2.7.8 (default, Oct 18 2014, 12:50:18)
         Jinja2: 2.7.3
       M2Crypto: 0.21.1
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.11
          PyZMQ: 14.4.0
            ZMQ: 4.0.5

The master is on OSX (installed via macports)

$ salt --versions-report
           Salt: 2014.1.0
         Python: 2.7.9 (default, Dec 13 2014, 15:13:49)
         Jinja2: 2.7.3
       M2Crypto: 0.22
 msgpack-python: 0.4.5
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.11
          PyZMQ: 14.5.0
            ZMQ: 3.2.5

Note that I believe the reported version on OSX to be incorrect, because the version specified in the Portfile is 2014.1.13 (as given in branch develop, pkg/macports/ports/sysutils/salt/Portfile)

Thanks!

[jfindlay]

Sorry to be picky, but is it possible for you to try upgrading to 2014.7.2 since 2014.1.13 is no longer supported and there are many good changes and fixes in 2014.7.2 that 2014.1.13 doesn't have. Thanks.

[shahn]

I did that, now the versions report is thus (again, the master is likely to be incorrect, I don't know exactly why that is but I used the 2014.7.2 file):

$ salt-minion --versions-report
           Salt: 2014.7.1
         Python: 2.7.8 (default, Oct 18 2014, 12:50:18)
         Jinja2: 2.7.3
       M2Crypto: 0.21.1
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.11
          ioflo: Not Installed
          PyZMQ: 14.4.0
           RAET: Not Installed
            ZMQ: 4.0.5
           Mako: Not Installed

$ salt --versions-report
           Salt: 2014.7.0
         Python: 2.7.9 (default, Dec 13 2014, 15:13:49)
         Jinja2: 2.7.3
       M2Crypto: 0.22
 msgpack-python: 0.4.5
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.11
          ioflo: Not Installed
          PyZMQ: 14.5.0
           RAET: Not Installed
            ZMQ: 3.2.5
           Mako: 1.0.1

[tsaridas]

@shahn @jfindlay
The below works for me

 file.recurse:
    - name: /etc/folder/next/

- watch:
    - file: /etc/folder/next/*

but when I remove the trailing / from /etc/folder/next then it throughs an error.

[basepi]

@shahn could we see your state that's failing? This is how I would recommend structuring it:

deploy_package:
  file.recurse:
    - name: /etc/package
    - source: salt://package

manage_service:
  service.running:
    - name: myservice
    - watch:
      - file: deploy_package

I tend to always use explicit - name args, and use the state ID (first line) for requisites. It tends to be less fragile.

[shahn]

Somehow I missed the activity, I have long since solved this differently. This was the (beginning of the) state file, anyway:

apache2:
  pkg.installed:
    - require:
      - file: '/etc/apache2'
      - user: www-data
  service.running:
    - enable: True
    - reload: True
    - watch:
      - file: /etc/apache2
      - pkg: apache2
  user.present:
    - name: www-data
    - uid: 33
    - gid: 33
    - home: /var/www
    - shell: /usr/sbin/nologin
    - require:
      - group: www-data
  group.present:
    - name: www-data
    - gid: 33

/etc/apache2:
  file.recurse:
    - source: salt://apache2/apache2
    - user: root
    - group: root
    - dir_mode: '0755'
    - file_mode: '0644'
    - template: jinja

[stale[bot]]

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.

[shahn]

I don't see this bug as fixed. Also, I provided the requested information. This bug could still be closed as I worked around it.

[stale[bot]]

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

[stale[bot]]

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.