I was not able to reproduce this issue, but I didn't try with any significant number of events for the server I was deleting. While trying to reproduce this I noticed that the configuration dropdown to delete the server is missing in version 5.8.1.5 so I opened bug 1492216 to track that issue separately. I'm tempted to close this, but would like to propose changing the dependent destroy to an after destroy callback which queues the deletion of the events. This should prevent the call to destroy the server from hanging, but I'm not sure what kind of problems the hanging reference to the removed server would cause. Thoughts?
I think if server stopped and there were no activity for some time than it is OK to delete server first and replace dependent=>destroy with after_destroy for EventStream. Gregg, what do you think?
https://github.com/ManageIQ/manageiq/pull/15995
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/79ca041e68148f98c3506614416f3ebd4ee569f8 commit 79ca041e68148f98c3506614416f3ebd4ee569f8 Author: Yuri Rudman <yrudman> AuthorDate: Tue Sep 19 13:35:12 2017 -0400 Commit: Yuri Rudman <yrudman> CommitDate: Wed Sep 20 15:07:05 2017 -0400 queue deletion of lihked events instead of dependent=>destroy. It should prevent UI to hang when deleting instance of MiqServer https://bugzilla.redhat.com/show_bug.cgi?id=1446585 app/models/miq_server.rb | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
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, 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-2018:0380