https://github.com/ManageIQ/manageiq/pull/18106
I followed the steps from here https://bugzilla.redhat.com/show_bug.cgi?id=1618530#c16 and I can see such message during the retirement: [----] I, [2018-11-12T05:49:38.299951 #15155:b2f124] INFO -- : MIQ(MiqEvent#process_evm_event) target = [#<Service id: 5, name: "Test-20181112-043955", description: "", guid: "43aadeb4-c691-494a-94cb-91542bc192c 0", type: nil, service_template_id: 4, options: {:dialog=>{"dialog_text_box_1_1"=>"qwfr"}}, display: true, created_at: "2018-11-12 09:39:49", updated_at: "2018-11-12 10:49:32", evm_owner_id: 1, miq_group_id: 2, r etired: false, retires_on: "2018-11-12 10:42:08", retirement_warn: 0, retirement_last_warn: "2018-11-12 10:49:32", retirement_state: "initializing", retirement_requester: "#<User:0x0000000013cfd560>", tenant_id: 1, ancestry: nil, initiator: "user">] it seems "retirement_requester" shows something wrong, because in 5.10 it shows a correct user id.
Thanks for verifying this on latest, Dmitry. I wouldn't have expected it to work on 5.9 anything yet because the fix is going to have to be a little different.
So I believe that the code that already got merged to the g branch is sufficient to fix this issue on g. I do however still think that comment 3 is a different bug. In order to verify this on g, you will simply need to set a service to retire in the future and then, when the retirement is complete, check that the retirement initiator is anything but "system". This was a different verification process than the same bug on master, because master included api changes that g didn't.
(In reply to drew uhlmann from comment #5) > So I believe that the code that already got merged to the g branch is > sufficient to fix this issue on g. I do however still think that comment 3 > is a different bug. > > In order to verify this on g, you will simply need to set a service to > retire in the future and then, when the retirement is complete, check that > the retirement initiator is anything but "system". > > This was a different verification process than the same bug on master, > because master included api changes that g didn't. I created a separate BZ https://bugzilla.redhat.com/show_bug.cgi?id=1649219. This issue is closed as verified in 5.9.6.0.20181105224828_652732b.
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:3816