foreman_expire_hosts is a plugin that allows users to define an expiration date for hosts. The hosts are then shut down as a first step and deleted after a grace period. To delete a host, I thought it was safe to just do a
This way, on can call host.destroy and the corresponding task is triggered as part of it. One of the reasons I guess @katello folks went with overriding the host destroy controller behaviour to actually redirect to the task details?
One possible approach would be to actually provide a canned action in foreman-tasks around the destroying (similarly what foreman_chef does) and if desired in katello, still overriding the controllers (which should be probably discouraged anyway), but doing something like:
redirect_to(foreman_tasks_task_path(@host.current_task.id)) # where we would expose the task triggered via the ActionTriggering there.
That would be at least the mid-term solution I would suggest. For the short term, you would probably need to check on presence of ::Actions::Katello::Host::Destroy and calling ForemanTasks.sync_task(::Actions::Katello::Host::Destroy, @host) in that case, which I agree is quite ugly way of doing things.
Host Destroy via the ui/api in katello is a syncronous task, so i don’t think that was it. Looking into our code history this goes back to 2014, so I dont’ think anyone is likely going to remember exactly why we did this. I think we should look into moving to the triggers that you mentioned are used in foreman_chef. We use them for host update and it tends to work well (as long as we’re careful).
please don’t redirect to the tasks page, if you want to show a progress, then please have a customized progress vs send the user to a generic tasks page.
I would also think that its OK to report back and say host is scheduled for deletion and expect the user to still see the host while its being deleted.
if it failed, we can probably send a notification via the notification drawer.