Description of problem: We have multi-region setup where we make API automation_request call to master region, eg. `{ "requester": { "auto_approve": true }, "uri_parts": { "namespace": "Integration/API", "class": "Methods", "instance": "Available_Keypairs" } }` We authenticate for API call using user "admin" with proper password. As we have the same "admin" user on all regions (including master with ID 91), there happen ERRORs as automation request ends with error due to user form another region is used for authentication. Version-Release number of selected component (if applicable): 4.5 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: request approval is not processed at master region, processing ends with error Expected results: Additional info:
Steps to Reproduce: 1. Create multi regional setup with user "admin" at all regions 2. At master region, deploy automate code that would be called through API as automation_request (eg. any code may be used althou easy to simulate using datastore attached to https://access.redhat.com/support/cases/#/case/01993946) 3. Make API call using "admin" user as in problem description - user from ANY region is used to perform automation_request (on ad-hoc basis may happen that there is used user from master region, in this case request proceed successfully)
If I understand correctly, you're making requests to the global region as "admin" and the incorrect "admin" user record is being used. I don't see any issues related to using the user from the wrong region. I have a two region setup with 2 admin users (1 from the global, 1 from the remote). I'm making automation requests to the global region API as the admin user. After 3000+ requests, none of them have used the admin user from the remote region as suggested. Is there any more information that can be provided to reproduce the problem? Also, I don't see that error in the logs attached to the support case.
Unless ":src_vm_id", ":src_id" or ":src_ids" are included in the request (which the first comment does not indicate), the request will be created in the region which received the API call by the logged in user. Only when one of the above keys is included will we forward the request to the appropriate region.
Looks like I was able to track down this issue. There is a User lookup based on the request object as part of the automate event processing that uses the userid name and it is not scoped to the region. Should be a simple fix and I would expect to have a PR available today. Specifically I we need to change this: @user ||= User.find_by(:userid => userid).tap do |u| to @user ||= User.in_my_region.find_by(:userid => userid).tap do |u| Here: https://github.com/ManageIQ/manageiq/blob/master/app/models/mixins/miq_request_mixin.rb#L34
https://github.com/ManageIQ/manageiq/pull/16756
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/faaf0f70acebc9b06ffe8c0bb5337c21a84ac605 commit faaf0f70acebc9b06ffe8c0bb5337c21a84ac605 Author: Brandon Dunne <brandondunne> AuthorDate: Fri Jan 5 16:22:08 2018 -0500 Commit: Brandon Dunne <brandondunne> CommitDate: Fri Jan 5 16:22:08 2018 -0500 Scope User and MiqGroup searches within the current region https://bugzilla.redhat.com/show_bug.cgi?id=1529995 app/models/mixins/miq_request_mixin.rb | 2 +- app/models/user.rb | 2 +- spec/models/mixins/miq_request_mixin.rb | 22 ++++++++++++++++++++++ spec/models/user_spec.rb | 9 +++++++++ 4 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 spec/models/mixins/miq_request_mixin.rb
(In reply to Greg McCullough from comment #9) > Looks like I was able to track down this issue. > > There is a User lookup based on the request object as part of the automate > event processing that uses the userid name and it is not scoped to the > region. Should be a simple fix and I would expect to have a PR available > today. > > Specifically I we need to change this: > @user ||= User.find_by(:userid => userid).tap do |u| > to > @user ||= User.in_my_region.find_by(:userid => userid).tap do |u| > > Here: > https://github.com/ManageIQ/manageiq/blob/master/app/models/mixins/ > miq_request_mixin.rb#L34 Hello Greg. That was I was trying to describe, that request is performed using user not in scope to the region. Thanks for root case identification and effective solution, Vaclav