Bug 1250202 - Unable to see heat templates in tenants other than admin
Unable to see heat templates in tenants other than admin
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
5.4.0
All All
high Severity high
: GA
: 5.5.0
Assigned To: Ladislav Smola
Pete Savage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 13:58 EDT by Josh Carter
Modified: 2015-12-08 08:25 EST (History)
13 users (show)

See Also:
Fixed In Version: 5.5.0.3
Doc Type: Bug Fix
Doc Text:
In the previous version of CloudForms Management Engine, heat templates could be found only in the admin tenant, and no other tenant. This bug was caused by an outdated Fog gem. This bug was fixed by updating the Fog gem version available on the appliance. Heat templates are now found in all tenants in the new version of CloudForms Management Engine.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-08 08:25:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1755783 None None None Never

  None (edit)
Description Josh Carter 2015-08-04 13:58:40 EDT
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@redhat.com
Comment 2 Greg Blomquist 2015-08-06 10:06:31 EDT
Ladas,

I thought maybe you had a PR for this already?
Comment 3 Ladislav Smola 2015-08-06 10:33:48 EDT
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?
Comment 8 Ladislav Smola 2015-09-17 05:09:02 EDT
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.
Comment 9 Ladislav Smola 2015-09-17 05:21:26 EDT
my guess is it was fixed by this https://github.com/fog/fog/commit/468f6acffe427f36f006a85fe0a0cfd0f38527f1

please try to update fog to 1.34
Comment 10 Faiaz Ahmed 2015-09-22 22:44:19 EDT
Hi Smola
I was wondering to how to update the fog? is there any specific steps we need to follow?

Regards
Faiaz
Comment 11 Ladislav Smola 2015-09-23 02:33:17 EDT
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.
Comment 12 Chen 2015-09-23 23:08:06 EDT
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
Comment 13 Ladislav Smola 2015-09-24 02:10:31 EDT
This looks fine when you want to use bundler, check with Greg Blomquist, I think there might be a packaged version you can update.
Comment 18 Greg Blomquist 2015-10-14 11:18:58 EDT
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.
Comment 20 Pete Savage 2015-10-26 17:48:53 EDT
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.
Comment 22 errata-xmlrpc 2015-12-08 08:25:39 EST
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

Note You need to log in before you can comment on or make changes to this bug.