Our investigation revealed a Service retirement issue when retirement is initiated through the internal scheduler. Since retirement is not being run in the user context, the User.current_user being used in retirement is unreliable.
Hey Yoder, I don't believe it's the custom code that's the issue on this ticket. I'm in the process of finding a solution. It's a valid bug.
Hi Yoder, I'm sorry I haven't provided a recent update. We've identified the issue, and are working on a fix. Regards, Tina
New commit detected on ManageIQ/manageiq/hammer: https://github.com/ManageIQ/manageiq/commit/9b78d522d1c1e7c062a91e8415e26611a1969a8d commit 9b78d522d1c1e7c062a91e8415e26611a1969a8d Author: Keenan Brock <keenan> AuthorDate: Wed Oct 17 12:26:29 2018 -0400 Commit: Keenan Brock <keenan> CommitDate: Wed Oct 17 12:26:29 2018 -0400 Merge pull request #17951 from d-m-u/fixing_system_retirement_user Add retirement initiator context (cherry picked from commit e6664250502bfafdfdd6b3734618744ada79c9ea) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1618530 app/models/mixins/process_tasks_mixin.rb | 2 +- app/models/mixins/retirement_mixin.rb | 59 +- spec/models/orchestration_stack/retirement_management_spec.rb | 245 +- spec/models/service/retirement_management_spec.rb | 50 +- spec/models/vm/retirement_management_spec.rb | 64 +- 5 files changed, 226 insertions(+), 194 deletions(-)
Still on dev, sorry...
Okay, well Satoe says this is for Hammer, so the PR that got in yesterday fixes this on master/hammer only...
Satoe! I'm so sorry but I lied, https://github.com/ManageIQ/manageiq-api/pull/497 (not yet merged) should get in with this...
And https://github.com/ManageIQ/manageiq/pull/18109
Okay, ignore comment 12, please.
New commit detected on ManageIQ/manageiq-api/hammer: https://github.com/ManageIQ/manageiq-api/commit/50eef54e29152d2663c9a9792ac5130eb15ad6dd commit 50eef54e29152d2663c9a9792ac5130eb15ad6dd Author: Brandon Dunne <brandondunne> AuthorDate: Thu Oct 18 13:41:00 2018 -0400 Commit: Brandon Dunne <brandondunne> CommitDate: Thu Oct 18 13:41:00 2018 -0400 Merge pull request #497 from d-m-u/fixing_make_retire_request_call_with_user_thingyamabobbers_n_stuff_for_great_justice Need the user on this call (cherry picked from commit cf295f0a1782a2cc0f577d46ff030454f661e604) https://bugzilla.redhat.com/show_bug.cgi?id=1618530 app/controllers/api/base_controller/generic.rb | 4 +- 1 file changed, 2 insertions(+), 2 deletions(-)
Can you please provide verification steps?
You need a setup with multiple users. You will need to create a generic service, provision it, schedule the retirement for today, and then log in as a different user when the retirement time comes up and the log message should reflect that the owner of the service, the person who did the provisioning, rather than the current logged in user, should be the retirer (look for a log message that looks like https://github.com/ManageIQ/manageiq-api/commit/50eef54e29152d2663c9a9792ac5130eb15ad6dd#diff-45edabef479ad5b18da3cb6c9af8c54bR68)
(In reply to drew uhlmann from comment #16) > You need a setup with multiple users. You will need to create a generic > service, provision it, schedule the retirement for today, and then log in as > a different user when the retirement time comes up and the log message > should reflect that the owner of the service, the person who did the > provisioning, rather than the current logged in user, should be the retirer > (look for a log message that looks like > https://github.com/ManageIQ/manageiq-api/commit/ > 50eef54e29152d2663c9a9792ac5130eb15ad6dd#diff- > 45edabef479ad5b18da3cb6c9af8c54bR68) I followed the provided steps and I didn't find any similar message from the PR, this is what I found in the log instead: [----] 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">] I guess "retirement_requester: #<User:0x0000000013cfd560>" is what I need, but I cannot identify who is User:0x0000000013cfd560.
Hey Dmitry! Any chance you might please let me take a look at the reproducer evironment?
Fixed and verified on 5.10.0.23.20181106165157_92dd189. retirement_requester shows the correct user.
Hi Dmitry, As you point out in comment 17, the retirement_requester should be a userid, not a user object. Could you open a new ticket for this issue? Thanks, Tina
Hey Dmitry! So in comment 17, your message with the User object is the same line, with the same process id, as what you put in the 5.9 clone of this bug. I'm not convinced it's an issue on both versions. Could you please clarify which version it is that you're seeing the user object, not the userid, when you open the new ticket for that particular issue?
(In reply to Tina Fitzgerald from comment #20) > Hi Dmitry, > > As you point out in comment 17, the retirement_requester should be a userid, > not a user object. Could you open a new ticket for this issue? > > Thanks, > Tina Sorry for misunderstanding, this log excerpt is from CFME 5.9. In 5.10 there is no such issue.
(In reply to Tina Fitzgerald from comment #20) > Hi Dmitry, > > As you point out in comment 17, the retirement_requester should be a userid, > not a user object. Could you open a new ticket for this issue? > > Thanks, > Tina I created a separate BZ https://bugzilla.redhat.com/show_bug.cgi?id=1649219