Bug 1418993 - [RFE] Bulk actions does not create task for updating packages via katello-agent
Summary: [RFE] Bulk actions does not create task for updating packages via katello-agent
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Tasks Plugin
Version: 6.2.7
Hardware: Unspecified
OS: Unspecified
high vote
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Jan Hutař
: 1711072 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-03 11:35 UTC by Stefan Nemeth
Modified: 2021-09-09 12:06 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-01-30 20:50:52 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 23321 0 High Rejected Package install isn't logged in Tasks 2020-12-09 14:48:58 UTC
Red Hat Bugzilla 1316598 0 high CLOSED [RFE] Satellite 6.2 Remote Execution provider not based on SSH-keys 2021-12-10 14:36:40 UTC
Red Hat Knowledge Base (Solution) 3652821 0 None None None 2018-10-14 22:05:32 UTC

Internal Links: 1316598

Description Stefan Nemeth 2017-02-03 11:35:30 UTC
Description of problem:
Similar problem as in old BZ https://bugzilla.redhat.com/show_bug.cgi?id=1108106
is occurring again.

If you want to update packages via katello-agent using bulk actions, the task is not generated.

If everything is OK, the update will go thru with no generated task
When it should fail, for example katello-agent is not running, no task is generated and update not performed, so there is no way how to know, which content-hosts were successfully updated via katello-agent. 

Using remote execution works and generates the tasks.  

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Stop katello-agent on tested content-host
2.on satellite 6 webui go to hosts -> content hosts -> bulk actions -> select the tested host with stopped agent  -> packages -> update all packages via katello agent
3.check monitor -> tasks

Actual results:

No tasks created

Expected results:

task created with failed result. 

Additional info:

Comment 1 Brad Buckingham 2017-09-20 20:23:44 UTC
This bugzilla is actually a duplicate of bug 1108106.  Based on the discussion [1], Satellite 6.2 introduced the 'Remote Execution' feature and bulk actions with that feature will generate the associated tasks.  At this time, there are no plans to alter the behavior for the actions performed via katello-agent.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1108106#c15

*** This bug has been marked as a duplicate of bug 1108106 ***

Comment 5 Matt 2018-02-28 15:38:55 UTC
This is very frustrating that a parent/master task (with sub-tasks) is not created correctly when updating packages via katello-agent as a bulk action...especially when trying to install the satellite-6.3-tools-upgrade package on many systems at once via katello-agent (which is EXACTLY what the 6.2 -> 6.3 upgrade guide says to do: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.3/html/upgrading_and_updating_red_hat_satellite/upgrading_red_hat_satellite#upgrading_clients).

We do not use remote execution nor do we configure it to work anywhere in our setup (for security and other reasons), so using the katello-agent method is the only way to do this for our setup. (We don't use any provisioning functionality of Satellite 6 either.)

I would fully expect a task to be created for a bulk action package update/install/remove via katello-agent (with sub-tasks), just as one would be created for an action via katello-agent for a single system (or any other kinds of bulk actions).

I don't understand why this can't be made to work with katello-agent, just as has been done with remote execution??! Or is that the plan now, since this was re-opened as an RFE?

Any way this can be made a priority to fix in 6.3.x sometime soon??


Comment 6 Ivan Necas 2018-03-01 14:51:14 UTC
The difference between the remote execution and katello-agent approach is that in the remote execution case, the foreman-tasks process is involved directly in driving the execution of the tasks on per-host basis. While with katello-agent, we are sending the request for the execution to the pulp subsystem at once (one request for all the hosts involved), and we have no other visibility right now to the tasks on the pulp side on per-host basis, what we get back is just the summary of the task itself.

I'm not sure if pulp exposes this data or not, but even if it does, there is another question of scalability, as we would need to poll the task updates from the pulp for every single host (as there is no mechanism to get the pulp task updates otherwise currently).

Therefore, we are looking instead into providing the non-ssh functionality into the remote execution rather than tying to go over the obstacles I've just mentioned (https://bugzilla.redhat.com/show_bug.cgi?id=1316598 for tracking)

Comment 9 Ivan Necas 2018-11-02 07:50:39 UTC
Yes, I don't see us investing into katello-agent approach via pulp at this point, and closing in favour of https://bugzilla.redhat.com/show_bug.cgi?id=1316598. Marking as deferred rather then wontfix, becuase we will actually fix it, just not the way it's askedin the BZ

Comment 10 Raashika Raghuwanshi 2019-01-02 09:48:36 UTC
Hi Team,
IHAC who is facing the same issue. A task showing the status of bulk action is not generated. 

The workaround they're using is searching with "label = Actions::Katello::Host::UploadPackageProfile" once the job is completed so that they can proceed with the next action. But this is a very cumbersome approach and using Remote Execution is not an option for them because of the sudo roles that the security team will not give a green flag for. 

Do let me know if this request can still be worked on or if, as mentioned by Ivan, the bug https://bugzilla.redhat.com/show_bug.cgi?id=1316598 will be followed.

Thank you.

Comment 11 Bryan Kearney 2019-01-30 20:50:52 UTC
Ivans comment is correct. I am closing this back out.

Comment 12 Brad Buckingham 2019-06-07 13:29:19 UTC
*** Bug 1711072 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.