I ran some tests on version 5.5.0.13.20151201120956_653c0d4 and found that it appeared to work properly. My scenario: Top tenant user: admin group: EvmGroup-super_administrator tenant: top_tenant A new automate domain named "top_tenant" created by user "admin" Note - I copied the start retirement method from the "ManageIQ" domain so I could add logging about what domain it was running from. Sub tenant user: test group: park_rangers tenant: yosemite A new automate domain named "yosemite" created by user "test" Note - I copied the start retirement method from the "ManageIQ" domain so I could add logging about what domain it was running from. As user "test": Created a new generic service item called "tina_test". Provisioned service had the correct user, group and tenant ids for user "test". Retired service. Retirement methods executed from my "yosemite" domain which is correct. I would have suspected it would go through the "top_tenant" domain if was retiring as user "admin" [----] I, [2016-02-02T14:06:29.950477 #3087:2fe3024] INFO -- : <AEMethod start_retirement> TINA - executing retirement in yosemite domain: Does this scenario capture your use case? If not, what should I change? Thanks, Tina
The behavior differs in my environment using build: 5.5.0.13.20151201120956_653c0d4 Can you provide the following: 1. The build number using configure -> about. 2. Where did you get the tenant object logged in the "init" method referenced above? Can you provide a copy of that method?
The reason that the user is switched to admin during retirement is because the logged in user's group doesn't contain the service owner's group. When the service provision starts the ids are :user_id=>1000000000004, :miq_group_id=>1000000000056, :tenant_id=>1000000000002 Then there is a customer method which seems to be changing the tenant on the service. The method is /Gcloud/Cloud/Orchestration/Provisioning/StateMachines/Methods/setServiceIdentity This method has a log line which states that changing the tenant <AEMethod setserviceidentity> Set service tenant id to 1000000000018 The Service gets provisioned and the identity of the service is changed to evm_owner_id: 1000000000004, miq_group_id: 1000000000095, tenant_id: 1000000000018 The provisioning started with tenant_id of 1000000000002 and was changed to 1000000000018 And also the group is changed. Changing of the group this way causes the retirement to run as admin. Can we get some more details from the customer if they are trying to change the service tenant, group during provisioning. The user should be part of these groups if the user shouldn't get swapped with 'admin'
(In reply to mkanoor from comment #5) > The reason that the user is switched to admin during retirement is because > the logged in user's group doesn't contain the service owner's group. > > When the service provision starts the ids are > :user_id=>1000000000004, :miq_group_id=>1000000000056, > :tenant_id=>1000000000002 > > Then there is a customer method which seems to be changing the tenant on the > service. > The method is > /Gcloud/Cloud/Orchestration/Provisioning/StateMachines/Methods/ > setServiceIdentity > > This method has a log line which states that changing the tenant > <AEMethod setserviceidentity> Set service tenant id to 1000000000018 > > The Service gets provisioned and the identity of the service is changed to > evm_owner_id: 1000000000004, miq_group_id: 1000000000095, tenant_id: > 1000000000018 > > > The provisioning started with tenant_id of 1000000000002 and was changed to > 1000000000018 > And also the group is changed. > > Changing of the group this way causes the retirement to run as admin. > > Can we get some more details from the customer if they are trying to change > the service tenant, group during provisioning. > > The user should be part of these groups if the user shouldn't get swapped > with 'admin' thanks, that effectively was the problem and thanks to your update the case has been resolved! I'm creating https://access.redhat.com/solutions/2158341 to cover this problem, maybe you can help me expand it further?
Hi Felix, We added some content to your solution article. This is an important issue and we'd like to better understand how the customer modified the values and how they resolved the issue. Can you give us more detail about the customer environment? Could we have a copy of the setserviceidentity automate method? Thanks, Tina