action #162641
closedcoordination #132467: [epic] Prevent redundant salt state.apply actions that are executed in every call
Prevent redundant salt state.apply actions that are executed in every call - openqa-trigger-from-ibs-plugin
0%
Description
Motivation¶
We manage more and more machines within our salt infrastructure https://gitlab.suse.de/openqa/salt-states-openqa so it becomes more important to make sure that the high state is applied efficiently. Normally a recurring call of salt \* state.apply
should not take long and not do any changes on the system assuming that any previous call already applies all pending changes. So we should review the actions happening in recurring calls to state.apply
and change all state rules accordingly so that they are really only called if necessary. Currently there is only one problem remaining wich is the recurring call of script generations on OSD itself from openqa-trigger-from-ibs-plugin which we should address
openqa:~ # salt --no-color 'openqa.suse.de' --state-output=changes state.apply | grep -v 'Result.*Clean'
openqa.suse.de:
----------
ID: SUSE:SLE-15-SP6:GA:TEST
Function: cmd.run
Name: su geekotest -c 'mkdir -p SUSE:SLE-15-SP6:GA:TEST && python3 script/scriptgen.py SUSE:SLE-15-SP6:GA:TE
Result: True
Comment: Command "su geekotest -c 'mkdir -p SUSE:SLE-15-SP6:GA:TEST && python3 script/scriptgen.py SUSE:SLE-15-
un
Started: 15:36:04.146954
Duration: 212.952 ms
Changes:
----------
pid:
30433
retcode:
0
stderr:
stdout:
Generating scripts for SUSE:SLE-15-SP6:GA:TEST
OK
----------
ID: SUSE:SLE-15-SP6:GA:Staging:A
…
Acceptance criteria¶
- AC1: No redundant repeated actions visible when calling
salt 'openqa.suse.de' state.apply
- AC2: All necessary actions are still applied on the systems including scripts in /opt/openqa-trigger-from-ibs-plugin
Acceptance tests¶
- AT1-1: Given being logged in to OSD When calling
for i in {1..2}; do salt 'openqa.suse.de' state.apply; done
Then the second call applies no changes to any systems
Suggestions¶
- Find out why the script generation from openqa-trigger-from-ibs-plugin is so far triggered in salt high states everytime and move those calls to a better place.
Updated by okurz 6 months ago
- Related to action #161423: [timeboxed:10h] Incomplete config files on OSD due to salt - Improve salt state application from remotely accessible salt master size:S added
Updated by jbaier_cz 6 months ago
- Assignee set to jbaier_cz
I guess we can use the stateful argument which should take care of the script.
Updated by jbaier_cz 6 months ago
I drafted a quick MR which should trigger the script only if something changed. That itself should already cover both ACs right away. We might consider adding a way of running just this salt state (or honestly trigger the whole salt pipeline) to openqa-trigger-from-ibs-plugin repo. Maybe we can use multi-project-pipelines or trigger-a-multi-project-pipeline-by-using-the-api feature from Gitlab.
Updated by jbaier_cz 6 months ago
- Status changed from New to Resolved
AC1 and AC2 fulfilled:
----------
ID: SUSE:SLE-15-SP4:Update:Products:SLERT
Function: cmd.run
Name: su geekotest -c 'python3 script/scriptgen.py SUSE:SLE-15-SP4:Update:Products:SLERT'
Result: True
Comment: State was not run because none of the onchanges reqs changed
Started: 17:29:49.243579
Duration: 0.004 ms
Changes: