Project

General

Profile

Actions

action #168400

open

coordination #58184: [saga][epic][use case] full version control awareness within openQA

coordination #152847: [epic] version control awareness within openQA for test distributions

Improve locking scope of git_clone tasks size:S

Added by tinita 10 days ago. Updated 3 days ago.

Status:
Workable
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2024-10-17
Due date:
% Done:

0%

Estimated time:

Description

Motivation

In #164898 we replaced the automatic git fetch cron (fetchneedles) with minion jobs.

There are three possible improvements.

Resolve symlinks before enqueuing

Compare the following two minion jobs:

args:
- /var/lib/openqa/share/tests/microos: ~
  /var/lib/openqa/share/tests/microos/products/microos/needles: ~
args:
- /var/lib/openqa/share/tests/opensuse: ~
  /var/lib/openqa/share/tests/opensuse/products/opensuse/needles: ~

microos is a symlink to opensuse. The path resolving happens inside the minion job before getting the lock, but we can avoid creating the job by resolving the symlinks before enqueuing. That way we would profit from the feature to not repeat the same minion job in less than one minute.

Avoid fetch when we can check locally for existing ref

For the case when we get a certain git sha in CASEDIR, we currently blindly do a fetch, but we could avoid the fetch and first check locally if the ref is there, which might be likely (for shas only. For branches we must always fetch).
For example our investigation jobs usually specify a sha which is already present.
Avoiding git commands needing network is good.

# pseudo code
if ($ref !~ m/[^a-f0-9]/) {
    # sha
    git rev-parse  --verify $ref
    # if it's not there, fetch
}

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 used for Git tasks take symlinking of case/needle directories into account.

Related issues 1 (0 open1 closed)

Copied from openQA Project - action #164898: Replace fetchneedles with a minion job for the regular update of git repos size:MResolvedtinita

Actions
Actions #1

Updated by tinita 10 days ago

  • Copied from action #164898: Replace fetchneedles with a minion job for the regular update of git repos size:M added
Actions #2

Updated by okurz 10 days ago

  • Due date deleted (2024-10-18)
  • Target version set to Tools - Next
Actions #3

Updated by okurz 10 days ago

  • Target version changed from Tools - Next to Ready
Actions #4

Updated by livdywan 3 days ago

  • Subject changed from Improve locking scope of git_clone tasks to Improve locking scope of git_clone tasks size:S
  • Description updated (diff)
  • Status changed from New to Workable
Actions #5

Updated by tinita 3 days ago

A draft for the second item already exists: https://github.com/os-autoinst/openQA/pull/6017 Do not git fetch if requested sha is already present

Actions #6

Updated by tinita 3 days ago

Re

AC1: Minion locks used for Git tasks take symlinking of case/needle directories into account.

The minion locks already take symlinking into account. This is about resolving symlinks even before the minion job is created. The args of the job should contain already resolved paths.

Actions #7

Updated by tinita 3 days ago

Why is there only one AC for the first item in the list?
This ticket should probably have been split into three.

Actions

Also available in: Atom PDF