Bug 1237064 - Swift objects containing ironic extra data are not accessible by the admin user
Summary: Swift objects containing ironic extra data are not accessible by the admin user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ga
: Director
Assignee: John Trowbridge
QA Contact: Marius Cornea
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-30 10:07 UTC by Marius Cornea
Modified: 2015-08-05 13:57 UTC (History)
10 users (show)

Fixed In Version: instack-undercloud-2.1.2-20.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, the undercloud admin user did not have a 'swiftoperator' role on the service tenant. As a result, it was not possible for CloudForms Management Engine (CFME), which uses the admin user to access the swift objects. With this update, the undercloud admin user is given the 'swiftoperator' role on the service tenant, thus, allowing the admin user access to the swift objects by specifying the service tenant in the API request.
Clone Of:
Environment:
Last Closed: 2015-08-05 13:57:42 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Gerrithub.io 238249 None None None Never
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Marius Cornea 2015-06-30 10:07:06 UTC
Description of problem:
Swift objects containing ironic extra data are not accessible by the admin user on the undercloud node. 

Version-Release number of selected component (if applicable):
instack-undercloud-2.1.2-6.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy undercloud
2. Register nodes
3. Run introspection
4. source stackrc
5. swift list

Actual results:
Doesn't return anything.

Expected results:
I'd expect to get list of containers/object so we can access ironic data by using the admin user.

Additional info:
You need to use the ironic user and service tenant to get retrieve the objects.
We need the nodes data for the Cloudforms integration where we are using the admin user to connect to the undercloud services.

Comment 3 John Trowbridge 2015-06-30 13:22:17 UTC
It is a simple configuration change to store the swift objects on the admin tenant instead of the service tenant. However, I think it would be better to create a CFME service user, and access the data through that user.

I am also a bit concerned about CFME relying on the data in these objects directly, as I am planning on changing the underlying data structure to be more inherently descriptive. There is also a plan to have an actual API to query this data. Once that API is in place, I think it is better to only access the data through that API.

Would you be able to point me to how CFME is using this data, and what specific entries it needs? 

Also, how difficult will this be on the CFME side if it changes completely in the Liberty release?

Comment 4 Ladislav Smola 2015-06-30 15:14:54 UTC
We are getting details about CPU, disks and networks. We were planning to show also the benchmark results. Basically any details are handy and can be presented in CFME.

I don't have a preference, whether it is exposed via API or just hash like before or just hash from swift. Anything stable and possibly documented will be good. 

We kinda relied on it being there for Kilo, as it was the plan to just have it in extra_attrs. So for us it would be better to have it exposed in swift and we can switch to API in liberty.

For the API, having it as part of the detailed list with pagination would be the best, so we don't have to do API request per node.

Comment 5 chris alfonso 2015-06-30 17:22:34 UTC
John, it sounds like we have options then. For our GA timeframe, we can have Ladislav add a user, access the swift api, and do their own pagination for now. Possible RFE.

Comment 7 Ladislav Smola 2015-07-01 08:53:53 UTC
How much of a problem would be to just allow admin user to read the data? Undercloud Swift is used just by ironic, correct? Or to just expose subset of the data into ironic extra_data?

I will have hard time adding another OpenStack user as part of one Provider into CFME.

Comment 8 John Trowbridge 2015-07-01 12:54:27 UTC
@Ladislav

It is not really a big issue to have discoverd/ahc-tools use the undercloud admin tenant for Swift. I will put up a patch for that.

Exposing a subset of the data is difficult, because the data is poorly structured for generic use. The structure is very specific to the architecture of the edeploy tooling. This is high on the priority list to change for Liberty, and why I think it would be a bad idea to write anything too complex around the existing data structure.

Comment 9 John Trowbridge 2015-07-01 20:02:02 UTC
posted a patch upstream: https://review.gerrithub.io/238249

Comment 10 John Trowbridge 2015-07-02 16:32:36 UTC
@Ladislav

We were able to find a compromise for this. We will add the swiftoperator role to the admin user on the service tenant. This will allow CFME to get to the swift objects by specifiying the service tenant in the API request.

Comment 12 Marius Cornea 2015-07-13 21:26:49 UTC
It doesn't seem that the swiftoperator role gets assigned:

[stack@instack ~]$ rpm -qa | grep instack-undercloud
instack-undercloud-2.1.2-17.el7ost.noarch
[stack@instack ~]$ openstack role list --user admin --project service

[stack@instack ~]$

Comment 13 Dmitry Tantsur 2015-07-14 08:26:28 UTC
Seems like we have diverge between dist-git and package itself. I've installed 2.1.2-19.el7ost and file /usr/share/instack-undercloud/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role does not have executable rights. In dist-git it seems to have them, however.

$ ls -l /usr/share/instack-undercloud/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role
-rw-r--r--. 1 root root 424 Jul 10 11:39 /usr/share/instack-undercloud/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role

$ git co rhos-7.0-patches
$ ls -l elements/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role 
-rwxrwxr-x. 1 dtantsur dtantsur 424 Jul 13 11:26 elements/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role

Mike, do you have an idea why it could happen? The SRPM looks correct, the RPM does not..

Comment 14 Dmitry Tantsur 2015-07-14 11:01:38 UTC
Even with file properly executed, the work around does not seem to work:

$ sudo bash /usr/share/instack-undercloud/ironic-discoverd/os-refresh-config/post-configure.d/99-admin-swiftoperator-role
$ swift list ironic-discoverd
Container 'ironic-discoverd' not found
$ OS_USERNAME=ironic OS_TENANT_NAME=service OS_PASSWORD=... swift list ironic-discoverd
extra_hardware-acbfc2d3-49bf-441a-85bc-c26eecab63d7
extra_hardware-c3037add-962f-4f5b-a030-353c1633fccf

Comment 15 Dmitry Tantsur 2015-07-14 11:04:21 UTC
Nevermind, sorry. I didn't realize the correct command is
$ OS_TENANT_NAME=service swift list ironic-discoverd
extra_hardware-acbfc2d3-49bf-441a-85bc-c26eecab63d7
extra_hardware-c3037add-962f-4f5b-a030-353c1633fccf

Comment 16 Mike Burns 2015-07-14 12:51:49 UTC
This is a problem with building rpms from tarballs + patches.  New files don't always get the right permissions for some reason.  The fix is a relatively simple spec patch.  New build coming shortly

Comment 18 Marius Cornea 2015-07-21 08:16:09 UTC
[stack@instack ~]$ rpm -qa | grep instack-undercloud
instack-undercloud-2.1.2-21.el7ost.noarch
[stack@instack ~]$ openstack role list --user admin --project service
+----------------------------------+---------------+---------+-------+
| ID                               | Name          | Project | User  |
+----------------------------------+---------------+---------+-------+
| e4e60528468141c2a7635e30ee178937 | swiftoperator | service | admin |
+----------------------------------+---------------+---------+-------+

Comment 20 errata-xmlrpc 2015-08-05 13:57:42 UTC
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/RHEA-2015:1549


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