Bug 1873408
| Summary: | Updating the CDN URL is manifest works fine but creates some tasks which remains in planned state with success result | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Sayan Das <saydas> |
| Component: | Repositories | Assignee: | Justin Sherrill <jsherril> |
| Status: | CLOSED ERRATA | QA Contact: | Stephen Wadeley <swadeley> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.8.0 | CC: | aruzicka, jsherril, oezr, pcreech |
| Target Milestone: | 6.8.0 | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | tfm-rubygem-katello-3.16.0.7-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 13:06:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sayan Das
2020-08-28 08:26:21 UTC
This is a funny one 1) Finalize phase of an action starts 2) The action kicks off a couple of Actions::Katello::Repository::UpdateCVRepoCertGuard tasks as async tasks from its finalize phase 3) The execution plan gets created *outside* of the transaction by Sequel 4) There is a hook which updates tasks when state of execution plans in dynflow changes, this hook gets triggered, but since it is still running in the same thread it is *inside* the transaction controlled by ActiveRecord 5) The hook moves the task to planned-success 6) Execution of the child task is handed off to the executor, possibly to another thread/process, definitely outside the still open ActiveRecord transaction 7) The execution of the child task finishes, but since it is outside the ActiveRecord transaction, from its point of view there is no task because the transaction wasn't commited yet 8) Finalize phase of the original action ends, changes get commited to the db, child task stays in planned-success Possible solutions: 1) Do not to kick off tasks from finalize phase, maybe make those tasks part of the main execution plan? 1a) Make them part of main execution plan 1b) Kick them off at the end of run 1c) Kick them off from execution plan hooks 1d) Kick them off from finalize, but set them to execute in the future to make sure the original transaction is commited by the time they start to run 2) Run the task update hooks in their own thread with their own active record connection. This is probably the correct way to go about this, but given the recent issues with db connection pools it also feels like a potential footgun CC oezr & jsherrill : Opinions on the above? Do you have any other idea how we could go about this? Holding off with setting devel_triaged until we decide which way we want to fix this, since it may involve a component change. Couple of comments: 1) This really shouldn't be triggered as part of cdn url update, it was an unintended side effect. I think a small code bug here is causing it: https://github.com/Katello/katello/blob/master/app/lib/actions/katello/repository/update.rb#L11 in this case, its intended to check for a change, but is not handling the case when nil is being passed in (and thus no change needed) 2) I think it could either be kicked off in the run phase, or planned as part of the overall action. One reason to do it in the run phase is to reduce the amount of async work done as part of a repo update (as katello's endpoint is syncronous, even though an async task is done in the background..... not good, but thats another bug for another day). So for now my vote would be run phase Created redmine issue https://projects.theforeman.org/issues/30736 from this bug Upstream bug assigned to jsherril Upstream bug assigned to jsherril Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30736 has been resolved. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.8 release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:4366 |