Red Hat Bugzilla – Bug 1247244
Object Store does not exist in Horizon after installing Swift manually
Last modified: 2017-05-11 23:07:31 EDT
Description: Hi folks. When using the rhel-osp-installer on RHEL-OSP6 (RHEL7.1) to build an OpenStack deployment, it seems that after following the instructions listed here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Deploying_OpenStack_Learning_Environments/chap-OpenStack_Object_Storage_Service_Installation.html the Horizon dashboard does not contain the "Object Store" tab necessary for viewing Swift related information. I believe the project name is "containers". Trying to manually enter the URL results in a "You don't have permission to access..." error. All CLI based commands function normally and Swift itself is configured fine after following the instructions above.
If I build a system with Packstack in OSP5 and set CONFIG_SWIFT_INSTALL=y, the tab appears correctly.
Additionally, BZ #1172467 appears to be a similar issue, although the workaround of setting the following does not work in my environment. I still cannot see Swift in Horizon.
use = egg:swift#keystoneauth
operator_roles = admin, SwiftOperator, _member_
Please advise as to what is necessary to get
Details: Base install of RHEL-OSP6 with partner provided key.
Bugzilla dependencies (if any): N/A
Hardware dependencies (if any): N/A
Date it will be upstream: N/A
Severity (U/H/M/L): M
Business Priority: Nice to Have
I'm moving the component to Horizon, so that a relevant developer may
assist in nailing this down. Not implying that Horizon is necessarily
at fault. But I cannot tell what's up in this at all.
I just completed a Packstack installation on a RHEL7.1 system with OSP6 repositories. The dashboard/project/containers is visible and accessible.
Where can I begin to diagnose this to see where the manual installation instructions are failing? I have to use the rhel-osp-installer, as it does not unfortunately configure Swift as a part of an OpenStack deployment.
do you have added swift to keystone catalog and your cli user can interact with swift?
should contain something like Service: object-store
The same could be checked in http://<your dashboard ip>/dashboard/admin/info/
there needs to be a swift endpoint.
Hi Matthias. I have added Swift to keystone and the CLI can interact with it successfully. I have uploaded and deleted objects successfully with both the admin and another tenant.
I have the object store service configured already:
keystone service-create --name swift --type object-store --description "OpenStack Object Storage"
Regarding the endpoint at /dashboard/admin/info/ I see
The rest of the services have an IP address and Enabled in the status field. Could this be the problem? Where can I fix this?
I figured this out, kind of painful not really knowing where to look in the logs. It's the region name that's used during endpoint creation that's the problem. Running the keystone endpoint-create command without a region specified defaults to "regionOne".
Instead of "regionOne", it needs to be "RegionOne".
This page really needs to be updated to include a "--region RegionOne" specification during the creation of the Keystone endpoint to match everything else:
PackStack is RegionOne, as are installs from the rhel-osp-installer.
Glad you figured it out.
I'll change the component here to docs, to get docs updated.
Has the doc been updated on this yet? Looks like it's still wrong.
Thank you for raising this bug.
My apologies for not responding sooner - I can now see this one was moved over from a different component, and my apologies for not having reached out to you already with regards to progress.
A separate bug - BZ#1297256 - was also raised requesting this change, and the required changes have now been implemented in the Installation Reference in the OSP 7 documentation, and will be carried over into the OSP 8 documentation as well.
I will close this bug as a duplicate for now, but please let me know if you feel additional changes are required, or if you have any separate requests.
Thank you once again for your feedback.
*** This bug has been marked as a duplicate of bug 1297256 ***