wenottingham
commented
3 years ago Not commenting specifically before or against this, just noting that the level of design that would go into a feature like this is fairly high. By constraining it to admins, it's not something you'd implement in the core ansible language, and trying to tie this to job execution, it would involve a fairly large redesign of how both workflows and templates work.
ISSUE TYPE
SUMMARY
Who benefits from this feature?: Organizations benefit from the ability to have governance with less points of failure and less overhead. If implemented into mature ci/cd piplines it would enable the org to further enhance their security. Smaller teams that cannot implement mature ci/cd pipelines to help manage and enforce code would benefit. This would allow for enhanced behaviors or workflows in environments where teams have customized this prerun/precheck to fit their environment accordingly, such as integration into CMDB, other workflows or plays, etc.
Needs or objectives from this feature: This specific customer wants the code for governance however it can be used for different use cases. I will discuss these now.
Req: The ability to run a play/playbook before any playbook/workflow at a global level outside of the end-users control or playbooks. (Think the way gather_facts can be set to run before every playbook.)
Potentially Optional: The ability to run a play/playbook after any playbook/workflow at a global level outside of the end-users control or playbooks. (Think the way gather_facts can be set to run before every playbook.)
NOTE: This is to give Admins increased flexibility and control. It accelerates "their customer's" onboarding and usage and removes the potential for human error when complying with org policies.
Use Case: The user wants to ensure appropriate CMDB information is correct prior to the run of a user's code, preventing "unapproved" ad-hoc runs. The user wants to ensure appropriate security of plays being run in the playbook avoiding an "injection" of sorts that is designed to circumvent their ci/cd pipeline. The user wants to ensure appropriate updates or workflows are triggered regarding their ITSM workflows prior to a play. The user wants to ensure appropriate updates or workflows are triggered regarding their ITSM workflows prior to a play.
Out of scope : Utilization of Agents What does success look like?: Success looks like a feature similar to "Gathering_Facts" that could be enabled (or is always on) that could be customized further to run additional plays. This could be something Gathering_facts is bundled into. This would be able to run before and after plays or workflows. This would be available to admins only and apply to the environment. This would be able to handle exceptions and not cause the environment to be unstable. The use of this feature would be supported by Red Hat.