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 ***

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??

Thanks.

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)

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

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.

Ivans comment is correct. I am closing this back out.

*** Bug 1711072 has been marked as a duplicate of this bug. ***