Rename _schedule.conf on YAML parse error

[marbx]

What issues does this PR fix?

• [BUG] Windows salt-minions spontaneously go into restart loop. Since 3001 massive CPU load #58177 -- 3001 --- Massive CPU load in restart loop
• salt-minion in restart loop #56216 -- 2019.9.2 -- salt-minion in restart loop

Merge requirements satisfied?

• Docs
• Changelog - https://docs.saltstack.com/en/master/topics/development/changelog.html
• Tests written/updated

[DmitryKuzmenko]

@markuskramerIgitt Personally I don't like the idea to remove any data that is possibly edited by user. Maybe it's better to just skip and keep it?

[marbx]

@DmitryKuzmenko you are right, I took over your suggestion.
This enables me to analyze how often minions invalidate their configurations.
In the long run, someone need to understand why the salt-minion writes NUL into _schedule.conf

@twangboy thank you for the test code!
I adapted your code (rename instead or remove).

[DmitryKuzmenko]

@markuskramerIgitt could you please resolve lint and pre-commit issues? Also your test code should be added to tests/unit/test_config.py instead of tests/unit/config/test_config.py.

[marbx]

@markuskramerIgitt could you please resolve lint and pre-commit issues? Also your test code should be added to tests/unit/test_config.py instead of tests/unit/config/test_config.py.

@DmitryKuzmenko where shall I add the test?

Is this related to the error from unit.test_module_names.BadTestModuleNamesTestCase.test_module_name_source_match

The following 1 test module(s) could not be matched to a source code file:
unit.config.test_config (expected: salt\config\config.py)

How do I run the test locally?

[DmitryKuzmenko]

@markuskramerIgitt you shall move your test code from your new file tests/unit/config/test_config.py to the existing one tests/unit/test_config.py. This is related to the test failure because the test system is validating file names match. If you are testing a code from subdir/__init__.py you shall to use test_subdir.py name.

[DmitryKuzmenko]

@markuskramerIgitt sorry, I've missed the question about running tests.
To run tests locally you can use nox like this:

$ nox -e 'pytest-zeromq-3.8(coverage=False)' -- -v --run-slow tests/unit/test_config.py

To run pre-commit hooks you can use this command:

$ pre-commit run salt/config/__init__.py

Surely you need to install the related dependencies like pre-commit and nox

[marbx]

@dwoz All checks have passed. Could you please remove the has-failing-test label?

[marbx]

@sagetherage you removed "merge-ready":

ci/py3/freebsd121 fails with "Caused: hudson.plugins.git.GitException: Could not checkout 4d7f55c"

I assume this is unrelated to this PR, please support.

Also, a number of unrelated ("boto") files are in the PR - I assume because I used a

git checkout --theirs FILE-WITH-MERGE-CONFLICT

does it help if I create a new PR?

[DmitryKuzmenko]

@markuskramerIgitt please don't care about it. The Merge-ready tag is just dropped from labels because we've found it useless. We don't use it to decide merge a PR or not. The decision is based on CI checks, code review and having tests covering the change.

[OrangeDog]

This PR's commits are a big mess.
There are 16 separate "delete_schedule_conf_on_yaml_parse_error", for example.
This should not have been merged in this state.

It's also caused bugs completely unrelated to _schedule.conf

[marbx]

@OrangeDog I agree that my commits to this PR are confusing

Next occasion I will scratch a PR branch with more than one commit and open a new one with a single commit.

The reason for renaming a broken _schedule.conf file is that 1) the minion will no longer contact or respond to the master and 2) the Windows client generates a high CPU load.

[OrangeDog]

a new one with a single commit

No, don't do that either. Rebase and/or amend so all the fixes go in the correct commits and force push. Don't use the same message for multiple commits.

[marbx]

a new one with a single commit

No, don't do that either. Rebase and/or amend so all the fixes go in the correct commits and force push.

@OrangeDog,
I try to understand what happened.

In August I made a Rebase and resolved conflicts by git checkout --theirs FILE-WITH-MERGE-CONFLICT
As far as I can remember, I only did that for "my files", and as far as I understand rebasing, this is an inevitable step in rebasing.
So far this caused no problem.

The boto files where introduced into this PR by this rebase.
As far as I understand, this is the purpose of a rebase: to add changes to the PR that happened on master after one created the branch.

So far still no problem: "unrelated files" are regular part of a rebased PR.

Where I think the problem arises, is that "unrelated files" should or even must not be changed.
In this PR, the changes where fatal.

Is that correct?

[OrangeDog]

@markuskramerIgitt If those changes were on master then they wouldn't show up in this PR. You must have done something else, either pulling them from another branch, or reverting fixes that had already been merged. That is separate from the fact that your own changes include 16 identically-named commits.

The blame does not all fall on you. The reviewers should also have noticed and nobody should have merged this.