Difference between the onfail and onchanges requisites vs their new _any variants unclear

[forty8bits]

While the value added from the require_any and watch_any requisites introduced in v2018.3.0 is clear and useful, and the documentation explains this well, it's unclear to me how the behaviour of onfail_any and onchanges_any is supposed to differ from the standard onfail and onchanges requisites?

From the docs on onfail, confirming it uses OR logic:

Beginning in the 2016.11.0 release of Salt, onfail uses OR logic for multiple listed onfail requisites. Prior to the 2016.11.0 release, onfail used AND logic.

And for onchanges:

If a state has multiple onchanges requisites then the state will trigger if any of the watched states changes.

Perhaps onchanges would fail if any of the states listed failed, whereas onchanges_any wouldn't? It would be nice to have these ambiguities cleared up in the docs.

[gtmanfred]

@garethgreenaway can you take a look at this to clarify the docs?

Thanks,
Daniel

[garethgreenaway]

Upon closer investigation it appears that onfail_any and onfail & onchanges_any and onchanges respectively perform the same function. Since onfail and onchanges existed first, we should remove the onfail_any and onchanges_any.

[mattp-]

@garethgreenaway providing the inversion would be useful (onfail_all, onchanges_all)

[forty8bits]

I like the idea of _all and _any variants as it removes all ambiguity. I also like the idea of being able to use both variants to complement each other, for example require_all-ing a few states while also require_any-ing a few others to enable defining a combination multiple mandatory dependencies along with at-least-one-of multiple optional dependencies, although I realise that's out of the scope of this specific issue.

[mattp-]

@forty8bits other than onfail and onchanges, every other requisite is implicitly AND, alongside _any for its OR equivalent (ie, the require_all you mentioned is already what require is), its implemented and released. we're just missing the AND for onchanges/onfail to complete the set of possible situations.
fwiw, it seems onfail originally WAS using AND, but was switched with #22370 . I'm going to take a look and see how easy it will be to revert that logic for onfail_all / onchanges_all

[forty8bits]

@mattp- I understand that, I just meant migrating all requisites to be fully qualified with _all and _any across the board would be nicely consistent and unambiguous.

[mattp-]

@forty8bits aye, agreed. i think its pretty trivial to create aliases; will try to keep that in mind when I find some tuits to look at this 👍

[stale]

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.

[baby-gnu]

Hello.

I think this should stay open.

Regards.