feat(master): enable option to set master scheduler

kartnico commented 4 years ago

What type of PR is this?

Enable configuration of scheduling option on master : https://docs.saltstack.com/en/latest/topics/jobs/#scheduling-runners

Primary type

[ ] [build] Changes related to the build system
[ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[ ] [ci] Changes to the continuous integration configuration
[x] [feat] A new feature
[ ] [fix] A bug fix
[ ] [perf] A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert] A change used to revert a previous commit
[ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

[ ] [docs] Documentation changes
[ ] [test] Adding missing or correcting existing tests

Does this PR introduce a `BREAKING CHANGE`?

No.

Related issues and/or pull requests

https://github.com/saltstack-formulas/salt-formula/pull/323

Describe the changes you're proposing

Take the same implementation than minion configuration file : https://github.com/saltstack-formulas/salt-formula/pull/323

Documentation checklist

[ ] Updated the README (e.g. Available states).
[X] Updated pillar.example.

pull-assistant[bot] commented 4 years ago

Best reviewed: commit by commit

Optimal code review plan

feat(master): enable option to set master scheduler

Powered by Pull Assistant. Last update 3ab819a ... 3ab819a. Read the comment docs.

myii commented 4 years ago

@kartnico An important point to note is that we're in the process of deprecating the configuration using salt/files/master.d/f_defaults.conf -- rather, we've implemented TOFS here instead -- see the lengthy discussion at #398 and the deprecation thread at #417. However, that doesn't block this PR getting merged in the meantime, if it still proves useful -- the changes just won't be around eventually.

daks commented 4 years ago

@kartnico An important point to note is that we're in the process of deprecating the configuration using salt/files/master.d/f_defaults.conf -- rather, we've implemented TOFS here instead -- see the lengthy discussion at #398 and the deprecation thread at #417. However, that doesn't block this PR getting merged in the meantime, if it still proves useful -- the changes just won't be around eventually.

I have no idea what this implies to users of this formula (I don't know TOFS), I hope we document clearly what are the needed changes when we decide to implement this breaking change

myii commented 4 years ago

I have no idea what this implies to users of this formula (I don't know TOFS), I hope we document clearly what are the needed changes when we decide to implement this breaking change

@daks This is the specific comment that explains it: https://github.com/saltstack-formulas/salt-formula/pull/398#issuecomment-499354351. I've now linked to it in the main comment in #417 as well. Actually, the TOFS method is much simpler than the current pillar-based method. To transfer over, you just take your existing rendered .conf files and put them in the TOFS hierarchy at the right level. Straight files, not templates.

daks commented 4 years ago

I don't like the idea of just pushing files, that's not how I imagine config management, but OK.

saltstack-formulas / salt-formula