action #169261
closedcoordination #58184: [saga][epic][use case] full version control awareness within openQA
coordination #152847: [epic] version control awareness within openQA for test distributions
Reduce scope of minion locks size:S
Description
Motivation¶
Followup to #168400. In #164898 we replaced the automatic git fetch cron (fetchneedles) with minion jobs.
There are three possible improvements.
- Resolve symlinks before enqueuing => ALREADY DONE in #168400
- Avoid fetch when we can check locally for existing ref DONE
That leaves missing:
Reduce scope of minion locks¶
This is more complicated and maybe too much effort for little benefit, but:
In some cases we don't need to call any git commands that could conflict with other commands, e.g. just looking up the remote url.
Or the case mentioned in the previous section would be another command that would not interfere with other git tasks.
Any command that does not change anything.
For those we don't need a lock.
Only at that point where we see we have to do a fetch, we have to get the lock.
This reduces the chances of other tasks having to retry because it couldn't get a lock.
It's just problematic because if a task has two paths to update, and you only realize for the second one that you need the lock, you would have to retry, but you don't want to repeat the commands for the first path.
The notes
field could act as a kind of state which of the paths have already been done.
Acceptance criteria¶
- AC1: Minion locks related to Git repositories are held only while they are actually needed so parallel execution of code in Minion jobs is possible more often (and e.g. tasks for saving needles are blocked less likely)
Suggestions¶
- Abort if the code becomes unreasonably complicated (so it is not worth it)
- Use the
notes
field to save state between calls (to not do a previous step a second time)