Feature #36434
open
please return planned CapsuleSync tasks after publish/promote tasks are done
Description
Ohai,
when one does a publish (Actions::Katello::ContentView::ContentView) or promote (Actions::Katello::ContentView::PromoteToEnvironment),
there is a on_success hook to sync capsules (execution_plan_hooks.use :trigger_capsule_sync, :on => :success, that method does a ForemanTasks.async_task(ContentView::CapsuleSync)).
It would be interesting if the publish/promote tasks would be able to report back the IDs of those CapsuleSync tasks in their result (no idea if that is even possible, given it's a hook that triggers them), as that would allow automation to wait for those tasks to be finished before continuing (e.g. with a "promote", "sync capsules", "patch systems behind capsules" flow).
There is an obvious workaround for this: disable automatic capsule syncs and "manually" trigger them in automation (as then you get the task to wait for), but it seems like a hammer for a weird nail to me ;-)
So, RFE: please report follow up tasks that were scheduled if possible.
Updated by Evgeni Golov 12 months ago
Talked with Adam on IRC about that, and it's probably not possible today:
13:42 < Zhenech> aruzicka, when a task schedules another task via execution_plan_hooks, it it possible to know the IDs of the schedules tasks? (I filed https://projects.theforeman.org/issues/36434 for katello, but
not sure this is even possible right now)
13:46 < aruzicka> not really, unless you'd store that somewhere outside the action's output/input (please don't)
13:47 < Zhenech> :D
13:48 < aruzicka> although you could possibly go the other way around if that would help?
13:49 < Zhenech> I am not sure I know any ways around tasks
13:52 < aruzicka> as in, the tasks kicked off from the hooks could know who kicked them off
14:07 < Zhenech> ah. yeah. but that doesn't help in my case (I kicked off the main task, I want to wait until both tasks are done, so I need to know what to wait for)
14:09 < aruzicka> maybe you could trick tasks into thinking the children are actually subtasks, but i'm not sure if that wouldn't conflict with something else
14:21 < Zhenech> aruzicka, mhh, with the current structure, would the CapsuleSync task exist in the DB already the moment the app returns success to the client? as in: could I just search for any CapsuleSync tasks
that have state != stopped and find it?
14:22 < aruzicka> Zhenech: it should
14:23 < Zhenech> kk, thanks. will try that out!
Updated by
Updated by Diego Abelenda 12 months ago
At least from the perspective of the use-case I defined in https://github.com/theforeman/foreman-ansible-modules/issues/1609
it would be sufficient to have an attribute in the CapsuleSync Task indicating which Promote Task triggered its creation. As long as it is possible to search for Tasks using this criteria.
If it is generic and there is a field that indicates which Task triggered the creation of the current task, it might be useful in other cases.
I am not involved in the internals of the Foreman/Katello projects, but conceptually this does seem a reasonable change.