Description of problem:
When a user that resides in a child tenant submits a create_provision_request from a generic service catalog item they cannot see the miq_provision_request in the Services / Requests page because the miq_provision_request for some reason is being assigned to the wrong tenant. This is currently affecting anyone using "build_request" in a CF multi-tenancy environment.
Version-Release number of selected component (if applicable):
5.5.2.4
How reproducible:
100%
Steps to Reproduce:
1. Create a child tenant
2. Create a group with self-service role and child tenant
3. Create a user associated to group
4. Create a service catalog item that runs create_provision_request
I.e.
args = ["1.1", {"guid"=>"043b2e64-eb15-11e5-b658-5254001018da", "name"=>"cirros"}, {"customization_template_id"=>"7", "security_groups"=>"44", "number_of_vms"=>"1", "cloud_tenant"=>"1", "vm_name"=>"changeme", "guest_access_key_pair"=>"39", "cloud_network"=>"14", "instance_type"=>"56", "number_of_sockets"=>"1", "cores_per_socket"=>"1", "vm_memory"=>"512", "retirement"=>"604800", "retirement_warn"=>"259200"}, {"user_name"=>"clouduser1", "owner_first_name"=>"cloud", "owner_last_name"=>"user1", "owner_email"=>"clouduser1.com"}, {"environment"=>"dev", "cloud_tenant"=>"project1", "flavor"=>"m1.tiny", "prov_scope"=>"tenant1"}, {"provider_id"=>"6", "flavor"=>"m1.tiny", "group_id"=>"19", "group_name"=>"group_tenant1", "cloud_tenant_id"=>"1", "guest_access_key_pair_name"=>"test-key", "cloud_network_name"=>"project1-private", "service_id"=>"55", "service_guid"=>"0a8f3a14-f5cc-11e5-b2d3-5254001018da", "environment"=>"dev", "cloud_tenant"=>"project1", "prov_scope"=>"tenant1"}, nil, nil]
request = $evm.execute('create_provision_request', *args)
5. You will see the service_template_provision_request is owned by the correct user and group and tenant. Yeah!
6. However after create_provision_request runs it creates a miq_provision_request and in the pg database it shows the correct user, group and the tenant id from the parent tenant.
7. What does this mean? If means that users living in sub-tenants cannot see their requests in the Services / Requests queue.
Actual results:
Users cannot see their miq_provision_requests
Expected results:
Users should see their miq_provision_requests
Additional info:
Description of problem: When a user that resides in a child tenant submits a create_provision_request from a generic service catalog item they cannot see the miq_provision_request in the Services / Requests page because the miq_provision_request for some reason is being assigned to the wrong tenant. This is currently affecting anyone using "build_request" in a CF multi-tenancy environment. Version-Release number of selected component (if applicable): 5.5.2.4 How reproducible: 100% Steps to Reproduce: 1. Create a child tenant 2. Create a group with self-service role and child tenant 3. Create a user associated to group 4. Create a service catalog item that runs create_provision_request I.e. args = ["1.1", {"guid"=>"043b2e64-eb15-11e5-b658-5254001018da", "name"=>"cirros"}, {"customization_template_id"=>"7", "security_groups"=>"44", "number_of_vms"=>"1", "cloud_tenant"=>"1", "vm_name"=>"changeme", "guest_access_key_pair"=>"39", "cloud_network"=>"14", "instance_type"=>"56", "number_of_sockets"=>"1", "cores_per_socket"=>"1", "vm_memory"=>"512", "retirement"=>"604800", "retirement_warn"=>"259200"}, {"user_name"=>"clouduser1", "owner_first_name"=>"cloud", "owner_last_name"=>"user1", "owner_email"=>"clouduser1.com"}, {"environment"=>"dev", "cloud_tenant"=>"project1", "flavor"=>"m1.tiny", "prov_scope"=>"tenant1"}, {"provider_id"=>"6", "flavor"=>"m1.tiny", "group_id"=>"19", "group_name"=>"group_tenant1", "cloud_tenant_id"=>"1", "guest_access_key_pair_name"=>"test-key", "cloud_network_name"=>"project1-private", "service_id"=>"55", "service_guid"=>"0a8f3a14-f5cc-11e5-b2d3-5254001018da", "environment"=>"dev", "cloud_tenant"=>"project1", "prov_scope"=>"tenant1"}, nil, nil] request = $evm.execute('create_provision_request', *args) 5. You will see the service_template_provision_request is owned by the correct user and group and tenant. Yeah! 6. However after create_provision_request runs it creates a miq_provision_request and in the pg database it shows the correct user, group and the tenant id from the parent tenant. 7. What does this mean? If means that users living in sub-tenants cannot see their requests in the Services / Requests queue. Actual results: Users cannot see their miq_provision_requests Expected results: Users should see their miq_provision_requests Additional info: