#39891 makes "legacy style" module.run states incompatible with future versions

[dkfsalt]

Description of Issue

GH-39891 creates a "legacy style XOR new style" situation where all old style states in the wild will no longer work, This means that there is a lot of community content that will simply fail to work once sodium is shipped.

This creates unnecessary work for anyone with states that work (if it ain't broke, don't fix it). It also means that anyone that's already chosen to use "new style" syntax can't use old style states without modifying them.

This is just a barrier to entry/usage of the system and I can foresee a situation where some people's production workloads will just stop working because of this when folks upgrade to sodium.

re: the warning that this is happening in Sodium - I was using the product for five months before I'd hit this issue - and if I'd not decided to "opt in" to the new syntax, I wouldn't have seen the issue until I'd upgraded to sodium. And it fails in a non-obvious way.

The module.run should be changed such that it can parse both the old and new style states.

Steps to Reproduce Issue

Run a new-style on a default pre-sodium system or run a legacy style state on a minion with the module.run set to superceded.

[thatch45]

Thanks, @dkfsalt, I completely agree.

[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.

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[cr1st1p]

I also recommend keeping old behavior always ON.
I have new style activated because I like it more, but I also depend on some external 3rd party formulas that are using the old style.

Also, I have to do more checks to find the real cause, but one of the formulas did NOT gave me any error but also did not do ANYTHING. After a couple of hours trying to figure out what was the issue, when I changed the formula to use the new module.run call style, it worked :-(

[xeacott]

@cr1st1p So I'll be handling these changes and I've been updating myself on all the issues/PR's open for this... and want to make sure we're on the same page (please correct me if my thinking is wrong 😄).

1. So we want to keep the old style enabled by default, with setting the following in the minion/master config files to actually use the new style by default.

use_superseded 
  - module.run

2. As well as removing the deprecation warning from the state, updating the docs surrounding the configs, and finally...
3. Adding logic to the state file to handle both of these situations (old by default, otherwise parse as new style).

Sound like a plan?

[cr1st1p]

First, strategically speaking, you guys have to decide what you want long term with the way of
using module.run - new style only or both?
If you decide you want to do it at some point, then you really need to:

• decide to do that in some kind of 'major' version change (2021.0 ?)
• clearly notify people very early, so they get a chance to change things
• clearly notify people that the new upcoming 2021.0? version will deprecate old style
• if possible, do a search on github for code that uses the old syntax and raise an issue in those projects

A. Anyway, you need to support BOTH ways of calling module.run. Either indefinitely, or until you deprecate it, based on
decision above.

Because you need to support both, as per A, automatically, there is no reason for the existence of the setting superseded: module.run

Task wise, then:
1 remove documentation references regarding superseded: module.run
2 remove code regarding that setting

3 wrap the current 2 versions of module.run in a separate function, that will do the detection of which implementation to run.
Independent of any setting, because you need to support BOTH modes regardless of any possible setting (which, as
said above, you should remove)
Implementation must be good, because it is important to correctly choose the implementation to run.
Also, it needs to take into consideration that user might have some mistakes in its calls.
4 update module.run documentation to say you support two modes; that preferably you should use the new one.
And, based on decision from the beginning of this text, that old style will be removed with version X
5 if decision is to deprecate old style at some point, add some deprecation warning, in code, on the old style implementation

I think you could start with 2 and 3 and maybe even release, until you get the decision in place.

Regards.