SEP 30: Event Driven State Enforcer

[garethgreenaway]

This feature addition would complete the journey that Salt has been on to be able to provide full configuration management and remediation when changes occur. An example of this would be using file.managed to create & manage a file, once that file has been created we would be to automatically monitor that file if/when any changes to the file occur. In the event that they do, Salt would be able to easily and automatically set the file into the desired state. Existing requisite systems are not being changed. This functionality is taking the existing pieces that many users use today to build these flow and add them in automatically, provided the option is enabled.

Proposed changes:

Phase 1: Associate state modules to beacon modules using a new mod_beacon function, eg. file state and inotify beacon. When specific functions include the necessary option, once they've manipulated a file then a beacon will be created that monitors that file for changes and generates an event.

Phrase 2: Explore the option of having the mod_beacon functionality being implemented in a more global fashion.

Phrase 3: Enable functionality that would allow reactors to be add automatically that would re-run the original state associated with the beacon.

was:

Title: Adding the ability to add beacons automatically from the state system

Body: Adding a SEP for change proposed changes to state system, adding the ability to add beacons automatically from the state system.

[max-arnold]

To be honest, right now, this looks like a limited use-case that was requested to be bolted-on without considering the broader context and long-term implications. It seems limited because a global state option is linked to a narrow function (beacons). And the broader context is that the ability to run arbitrary functions in response to particular states is much more powerful and flexible (and it is a more substantial reason to complicate the Salt state system).

Also, it is not entirely clear what specific use-cases require this change (the motivation sentence is quite vague: Adding this new option would allow beacons easier and associating them with Salt managed resources).

Have you considered a more generic implementation like the transparent requisites in Idem (or Salt executors, although they are much more limited)?

What I'm thinking about is having something like pre/post/onchange/onfail hooks that can be assigned to state functions globally (with the ability of more granular filtering based on state arguments and also enabling/disabling on a per-state basis). For example, it could possibly allow refactoring of the hardcoded file backup option into a hook (a global requisite).

Another critical point is that it should be possible to place these global hooks (requisites) into arbitrary (custom) modules and not just into the same module where the state resides. This will enable the development of custom global policies and automations for Salt states without altering existing modules and state files.

And finally, the pattern of adding functions like mod_watch on a per-module level didn't prove itself with time. For example, the fragmented and inconsistent mod_run_check implementation was recently refactored into a global one: https://github.com/saltstack/salt/pull/55974

[OrangeDog]

Could the same thing be achieved with a state that manages beacons, and the current available requisites?

[sagetherage]

This SEP does need some updates and phase 1 was implemented in Aluminium, prior to this being approved. That isn't the process and we made a mistake, here. @garethgreenaway between now and the next 2 weeks can you please make adjustments to this SEP and address the comments, please?

Here is the PR of Phase I https://github.com/saltstack/salt/pull/59559

[waynew]

Apologies for the long hiatus, we're working to refocus on getting SEPs through the process.

---

Summary of the current discussion:

There are questions as to whether or not this could be accomplished in another way, or if this could be improved by taking a more holistic view of the desired functionality.

[garethgreenaway]

The idea was to go beyond that is done with states and requisites, per the example in the SEP...you use file.managed to create a file, a running beacon would be added to the minion that watches that file for changes, and then fires an event, which runs the original state (or part of it) to put the file back. Obviously you can do all this manually setting up you're own reactors or using the beacon state module to create a beacon. Considering this could be a common use case, the idea here is to do it automatically within the state system without requiring the user to worry about creating the beacon state to manage the beacon or worry about having the proper requisites in place.