Bug 1618530
| Summary: | User ID for Service Retirement Task Changes During Retires When First Retirement Fails | |||
|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | myoder | |
| Component: | Automate | Assignee: | drew uhlmann <duhlmann> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Dmitry Misharov <dmisharo> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 5.9.0 | CC: | bwoolf, dmetzger, dmisharo, duhlmann, mkanoor, obarenbo, rovalent, simaishi, smallamp, tfitzger | |
| Target Milestone: | GA | Keywords: | TestOnly, ZStream | |
| Target Release: | 5.10.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | 5.10.0.21 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1640631 (view as bug list) | Environment: | ||
| Last Closed: | 2019-02-12 16:51:07 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | Bug | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | CFME Core | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1640631 | |||
|
Comment 3
Tina Fitzgerald
2018-08-29 14:58:17 UTC
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... 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 |