top.sls-like targeting for localmods

[eliasp]

When using Dynamic Module Distribution to distribute localmods, I do this most of the time to:

• temporarily work around an issue of an existing module
• distribute a single fixed module from the upcoming version until this version made its way into my distribution's package repository

I believe, this is what most people use localmods for.
With this approach, I'm running into the following issues:

• I have to manually keep track of each module when to drop it again
• I have no control over which Minions will receive a specific module or not (e.g. CentOS still has 2014.7.x, while Debian/Ubuntu already has 2015.5.x) which might then lead to compatibility conflicts.

I'd like to see a solution which provides more finegrained control over the the distribution of localmods, e.g.

• regular targeting based on grains etc.
• targeting based on Minion versions (e.g. <2015.5.0 or * and !2014.7.6 and !2015.5.0)

[arnisoph]

+1

[jfindlay]

@eliasp, thanks for the report.

[arnisoph]

I think #10105 is related to this.

IMHO version management is useful for state, execution, pillar, runner, returner, outputter and cloud drivers and all the others modules. Having this would be a huge killer-feature of salt.

[DanyC97]

+1111

[arnisoph]

@thatch45 I'd love to hear your opinion about this topic. it is hard to maintain (execution or any other) modules when you can't test them in an environment without using a separate salt master. I think having the possibility of specifying execution/state module versions on top.sls level would be useful for many people!

are there any other ways to solve this problem?

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

[eliasp]

Not stale at all!

[stale]

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

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