Issue #1173
closed
Content Applicability Regeneration for individual consumers is sent to a single worker
- Triaged changed from No to Yes
Eliminate the lock for individual consumer applicability calculation as part of this.
We'll need to be careful to ensure that multiple calculations can run safely in parallel. Maybe since we are already batching the calculation and farming it out for parallel execution, the problem is already solved? Is there anything different about doing this for a single consumer?
- Sprint/Milestone set to 31
- Sprint/Milestone changed from 31 to 32
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
- Status changed from ASSIGNED to NEW
- Assignee deleted (
ttereshc)
Unassigning since I am not working on that, solving other more high priority BZs.
Just in case someone would like to work on that.
- Sprint/Milestone changed from 32 to 33
- Status changed from NEW to ASSIGNED
- Assignee set to ttereshc
I think applicability calculation for individual consumers is sent to the single worker only in case the task for multiple consumers is triggered.
If one will use the task for single consumer the resource will be reserved for the particular consumer only so calculation for other consumers can be done by other workers.
- Status changed from ASSIGNED to CLOSED - WONTFIX
I suggest to use the API call for a single consumer when there is a need to calculate applicability for just one consumer (this is suitable for Katello use cases). Such tasks for different consumers will be sent to multiple workers. So this issue will be solved by using this API call.
Only when one triggers the applicabilty calculation for consumerS then such tasks will be sent to one worker only.
Please re-open this issue if you disagree and think that resource reservation for consumerS call should be removed.
- Sprint/Milestone deleted (
33)
Also available in: Atom
PDF