fix(apache.service.running): prevent recursive requisite

[dehnert]

PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

---

What type of PR is this?

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

This fixes the same issue as #388, but slightly more completely.

Describe the changes you're proposing

The fixes circular requisite errors when using the formula. Most of the change isn't mine (see the commit authors), but I added some tweaks, hence the new PR.

In terms of how the change works, mostly copying from my comment on #388

• The changes to apache/config/file.sls are all just s/require_in/watch_in/`. AIUI the watch requisite implies the require requisite, so these are required either way, this just means that we restart Apache if they change.
  • Almost all the changes to file.sls are in file.directory states. I think if Apache previously crashed, service.running would rerun anyway, and it's unlikely that Apache would run but incorrectly without these directories, so I don't see why watch_in is needed. OTOH, it's probably harmless.
  • The other one is in OS-dependent config files (the diff looks like deleted lines, because the require_in is getting combined with the watch_in). This seems like an improvement, though it's hard to see how it would improve a circular dep.
  • (My additional change is to add a watch_in for the main config file. This seems like it would be pretty important to getting appropriate config-reloading behavior.)
• The removed requisites (which are presumably how you break a loop) are in apache/service/running.sls.
  • The three apache-service-running* states lose their watch (and usually require, which AIUI is redundant) on sls: {{ sls_config_file }}, which AFAICT is just the whole apache.config.file from earlier in the PR. Effectively, in combination with the earlier changes, I think this is replacing a broad dependency from the running states on the whole config file sls (in running.sls) with narrow dependencies from the running states to each of the config file states (in file.sls). My guess is that require: sls: whatever requires everything in that SLS, including the includes, and we include {{ sls_service_running}}, which would make a loop.
  • -reload and -running lose their watch/require entirely (there's no consistent watch_in for them), but they're after the service: apache-service-running. I can't find a definition of after, but my guess is this functionally means we need apache-service-running's prereqs, which is good enough. (Also these shouldn't run all that much.)
• (I make a similar change in apache/config/modules/install.sls to use a finer-grained requisite there (based on danny-smit's patch)

I also reduce the amount of logging dumped to salt when Apache restarts -- the old parameters could really clutter the output, which was very apparent when circular deps meant it kept failing to restart.

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

• Updated the README (e.g. Available states).
• Updated pillar.example.

Testing checklist

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context