Skip to content

Fix run on start#61965

Merged
dwoz merged 5 commits into
saltstack:masterfrom
bugfood:fix-run_on_start
Jun 25, 2025
Merged

Fix run on start#61965
dwoz merged 5 commits into
saltstack:masterfrom
bugfood:fix-run_on_start

Conversation

@bugfood
Copy link
Copy Markdown
Contributor

@bugfood bugfood commented Apr 18, 2022

What does this PR do?

  1. Updates the default behavior of the run_on_start parameter to match the documentation and older salt behavior.
  2. Update/extend unit tests accordingly.

What issues does this PR fix or reference?

Fixes: #61964

Initial Behavior

Jobs with seconds/minutes/hours/days parameters would run on startup by default.

Regression from 391424c:

Such jobs no longer run on startup by default and need to be forced by `run_on_start: True'.

New Behavior

Such jobs now run on startup by default again.

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

Commits signed with GPG?

No

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

@bugfood bugfood requested a review from a team as a code owner April 18, 2022 22:33
@bugfood bugfood requested review from waynew and removed request for a team April 18, 2022 22:33
@welcome
Copy link
Copy Markdown

welcome Bot commented Apr 18, 2022

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

@OrangeDog
Copy link
Copy Markdown
Contributor

They should still, however, run at a random interval after startup depending on the splay parameter. Is that still the case?

Tests like test_eval_splay probably need some adjustment.

@bugfood
Copy link
Copy Markdown
Contributor Author

bugfood commented Apr 19, 2022

I do think that the splay parameter is still respected appropriately. I added a commit, just now, to make the splay testing more precise to verify this.

@bugfood
Copy link
Copy Markdown
Contributor Author

bugfood commented Apr 20, 2022

I think the test failure on this PR is unrelated to the changes I made.

@bugfood
Copy link
Copy Markdown
Contributor Author

bugfood commented Apr 2, 2025

Thanks for the interest in this old PR. I have not been active with saltstack work in the interim, but of course you can still use the changes if they are any good.

Wouldn't it be better to rebase this branch against current master rather than merge master into this branch?

@twangboy
Copy link
Copy Markdown
Contributor

Please rebase and fix the failing pre-commit

bugfood added 5 commits May 19, 2025 16:49
This internal parameter is written to but never read from.

The equivalent internal parameter _next_fire_time was introduced in
391424c; this parameter is actually used.
According to the document:
https://docs.saltproject.io/salt/user-guide/en/latest/topics/scheduler.html

   By default, any job scheduled based on the startup time of the minion
   will run the scheduled job when the minion starts up.

This was broken by 391424c and entrenched into the test suite by
various commits afterward.

Fix the code and adjust the unit tests to match. Add a new unit test to
ensure that disabling job run at startup still works.
This test is unlike the seconds, minutes, and hours tests; dry_run is
enabled unconditionally.
1. Ensure that jobs are run at minion startup as per the default
   `run_on_start: True`.
2. Ensure that jobs are not run before the splayed interval.
3. Update _check_last_run docstring to match behavior.
@bugfood
Copy link
Copy Markdown
Contributor Author

bugfood commented May 20, 2025

Please rebase and fix the failing pre-commit

Rebased and amended.

The pre-commit complaints seem to be about:

  • Wanting a rename of the file in changelog/; done.
  • Wanting formatting via Black; done.

I think the CI pipeline needs to triggered to run.

@dwoz dwoz merged commit e17e6ac into saltstack:master Jun 25, 2025
1434 of 1443 checks passed
@welcome
Copy link
Copy Markdown

welcome Bot commented Jun 25, 2025

Congratulations on your first PR being merged! 🎉

@dwoz
Copy link
Copy Markdown
Contributor

dwoz commented Jun 25, 2025

@bugfood

Is this regression present in 3006.x?

@bugfood
Copy link
Copy Markdown
Contributor Author

bugfood commented Jun 27, 2025

@bugfood

Is this regression present in 3006.x?

I think so, from looking at the code--there don't seem to have been any significant changes to the eval function on the v3006.13 branch in the time since I originally made this PR.

Thank you for the merge.

-Corey

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:full Run the full test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] [regression] jobs scheduled based on the startup time of the minion do not run at minion startup by default

4 participants