Project

General

Profile

Actions

Bug #25608

closed

Locks for tasks are created after planning phase, allowing 2 concurrent tasks on a "locked" object

Added by Adam Ruzicka about 6 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1655245

Description of problem:
There is a use case when manifest refresh task (or probably also other manifest related tasks) creates lock preventing concurrent manifest tasks - but too late. This allows multiple concurrent manifest tasks running.

The use case requires enabling or disabling some Red Hat repos, such that the task creates more Actions::Pulp::Repository::[UpdateImporter|RefreshDistributor] dynflow steps. This is a must for reproducer.

How reproducible:
100%

Steps to Reproduce:
1. Enable some random Red Hat repositories (at least 5)
2. Invoke two manifest refreshes almost concurrently
3. Try the same once again but with concurrent manifest refresh AND manifest import (this might trigger dangerous consequences, I guess).

Actual results:
2. and also 3. allows multiple manifest tasks running concurrently (and taking much more time than usual).

Expected results:
Neither 2. or 3. allows concurrent manifest tasks running.

Additional info:
hint for engineering: when you dont enable repos before the concurrent manifest refresh, the later task triggered will fail with "Required lock: .." error, as expected. So I think locking is done after generation of dynflow steps while it must be done before them..? (but if I am right, also concurrent CV tasks would be possible the same way..?)


Related issues 1 (0 open1 closed)

Related to foreman-tasks - Bug #32094: Mop up after split from locks to locks and linksClosedAdam RuzickaActions
Actions

Also available in: Atom PDF