Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

SEP 30: Event Driven State Enforcer #40

wants to merge 3 commits into
base: master
Choose a base branch


Copy link

@garethgreenaway garethgreenaway commented Dec 21, 2020

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.


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.

…ability to add states automatically from the state system.
@garethgreenaway garethgreenaway requested a review from a team as a code owner December 21, 2020 18:01
@garethgreenaway garethgreenaway requested review from Ch3LL and removed request for a team December 21, 2020 18:01
Copy link

max-arnold commented Dec 27, 2020

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: saltstack/salt#55974

@garethgreenaway garethgreenaway changed the title Aadding the ability to add beacons automatically from the state system Adding the ability to add beacons automatically from the state system Jan 1, 2021
Copy link

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

@garethgreenaway garethgreenaway changed the title Adding the ability to add beacons automatically from the state system Event Driven State Enforcer Jan 12, 2021
@garethgreenaway garethgreenaway changed the title Event Driven State Enforcer SEP 30: Event Driven State Enforcer Jan 25, 2021
@sagetherage sagetherage added the Draft Initial Status label Feb 5, 2021
@sagetherage sagetherage added Final Comment Period Speak now or forever hold your peace. and removed Draft Initial Status labels Feb 11, 2021
@sagetherage sagetherage added this to Final Comments in SEPherding Feb 12, 2021
Copy link

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 saltstack/salt#59559

@sagetherage sagetherage added Draft Initial Status and removed Final Comment Period Speak now or forever hold your peace. labels Apr 1, 2021
@sagetherage sagetherage moved this from Final Comments to Draft in SEPherding Apr 1, 2021
Copy link

waynew commented Jan 5, 2022

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.

Copy link
Contributor Author

The idea was to go beyond that is done with states and requisites, per the example in the 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Draft Initial Status
6 participants