action #175851
closed
coordination #161414: [epic] Improved salt based infrastructure management
Prevent re-evaluation of "stop_and_disable_all_not_configured_workers" state on every run size:S
Added by okurz about 1 month ago.
Updated 28 days ago.
Category:
Feature requests
Description
Observation¶
On salt --state-output=changes -C "G@roles:worker" state.apply the state "stop_and_disable_all_not_configured_workers" is always executed and listed as changed. For proper idempotent evaluation the state shouldn't be evaluated.
Acceptance criteria¶
- AC1: Running
state.apply on multiple OSD hosts repeatedly shows no changed states
Acceptance tests¶
- AT1-1: Run
ssh openqa.suse.de "sudo nice env runs=30 count-fail-ratio salt --state-output=changes -C '*' state.apply queue=True | grep -v 'Result.*Clean" and look for "Succeeded: $big_number" without "(changed=1)"
Suggestions¶
- Subject changed from Prevent re-evaluation of "stop_and_disable_all_not_configured_workers" state on every run to Prevent re-evaluation of "stop_and_disable_all_not_configured_workers" state on every run size:S
- Description updated (diff)
- Status changed from New to Workable
- Assignee set to jbaier_cz
- Description updated (diff)
- Status changed from Workable to In Progress
merged and deployed. From the deployment job in https://gitlab.suse.de/openqa/salt-states-openqa/-/jobs/3739365#L301 I still see stop_and_disable_all_not_configured_workers executed for sapworker1 but maybe somebody really applied some changes since the last run. At least diesel+petrol's output was clean. I suggest you run like 2-3 cycles of the salt state apply on at least one machine to verify and then resolve.
okurz wrote in #note-6:
merged and deployed. From the deployment job in https://gitlab.suse.de/openqa/salt-states-openqa/-/jobs/3739365#L301 I still see stop_and_disable_all_not_configured_workers executed for sapworker1 but maybe somebody really applied some changes since the last run. At least diesel+petrol's output was clean. I suggest you run like 2-3 cycles of the salt state apply on at least one machine to verify and then resolve.
Ah, no. That's a different problem in the same condition. We can actually only disable services (i.e. we can only make the first number lower). This is a proper fix (unless of course we want to support enabling the services): https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/1364
- Due date set to 2025-02-15
Setting due date based on mean cycle time of SUSE QE Tools
- Due date deleted (
2025-02-15)
- Status changed from In Progress to Resolved
Also available in: Atom
PDF