Description of problem: CloudForms discovery will find heat templates in the admin tenant but will not discover heat templates in any other tenant. The discovery will shows instances that were deployed by the heat templates in other tenants but will show none for source heat template in the instance details page. The user provided to CloudForms is the Openstack Admin and is a member of all of other tenants in Openstack. There is no change if you add heat_stack_owner or heat_stack_user roles to the admin profile in each tenant. Version-Release number of selected component (if applicable): 5.4.1 How reproducible: very Steps to Reproduce: 1. Have a Openstack env with two tenants Example admin and cfme 2. Create a heat template in the admin tenant 3. Create a heat template in the cfme tenant 4. Verify that the admin user has the following rights for the cfme tenant _member_, _heat_stack_owner (this is found in Identity, {tenant/project} Modify Users 5. Add the Openstack env to a CloudForms appliance and perform a discovery. 6. Once the refresh is completed you should see the admin heat template but not the cfme heat template Actual results: Expected results: Additional info: I have this reproduced in my lab please reach out ot me for access jocarter
Ladas, I thought maybe you had a PR for this already?
At some point, it will be solved by this https://github.com/ManageIQ/manageiq/pull/3278 , the patch that will rule them all. :-) The problem here is, it is doing stack.template, which is calling template_get under admin tenant. I think somebody had a similar issue, basically any validation that is calling e.g. get_instance and is not respecting tenant on that instance will get nothing. So the solution will be to have methods like handled_get(:template, :stack_id => id).first which will go through all tenants and find it or template = tenant_scope(stack.tenant) { stack.template } which in this case will ask the correct tenant right away? At least I think, that is what's going on by quick peek. :-) Question is will it wait for #3278, or this should have small backportable fix?
Can't reproduce it on master, I wrote also VCR tests, that are passing https://github.com/ManageIQ/manageiq/pull/4385 Only difference I see is the role is named "heat_stack_owner" Tests are currently covering Havana and Kilo with keystone v3.
my guess is it was fixed by this https://github.com/fog/fog/commit/468f6acffe427f36f006a85fe0a0cfd0f38527f1 please try to update fog to 1.34
Hi Smola I was wondering to how to update the fog? is there any specific steps we need to follow? Regards Faiaz
if you are using bundler, change the fog version in a Gemfile to 1.34.0 and run bundle update if you are using package, update the package Version has been updated in master, so this should be fixed.
Hi Smola, Are the following steps of updating the fog look fine to you ? 1. Disable SSL by changing the https from http in /var/www/miq/lib/Gemfile. source 'http://rubygems.org' 2. Adjust the version of fog from 1.29.0 to 1.34.0. gem "fog", "~>1.34.0", :require => false 3. Update fog. # bundle update fog 4. Remove the unnecessary version of fog. # bundle clean Best Regards, Chen
This looks fine when you want to use bundler, check with Greg Blomquist, I think there might be a packaged version you can update.
Chen and Faiaz, unfortunately, there is no way to run bundler on CloudForms appliances today. So, there is no easy way to update Fog for use by the CloudForms application on an appliance.
Verified in 5.5.0.7 However a new bug will need to be filed as the admin user needed admin role of the second tenant.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2551