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.
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?
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.
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.
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.
@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.
posted a patch upstream: https://review.gerrithub.io/238249
@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.
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 ~]$
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..
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
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
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
[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 | +----------------------------------+---------------+---------+-------+
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