Bug 977866 - Bad instructions for setting up glance for swift storage
Summary: Bad instructions for setting up glance for swift storage
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Installation_and_Configuration_Guide
Version: 3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.0
Assignee: Summer Long
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1011085
TreeView+ depends on / blocked
 
Reported: 2013-06-25 13:42 UTC by Attila Darazs
Modified: 2013-09-24 17:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Build: CSProcessor Builder Version 1.10 Build Name: 15807, Installation and Configuration Guide-3-1 Build Date: 20-06-2013 16:46:44 Topic ID: 15934-460335 [Latest]
Last Closed: 2013-07-24 19:14:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Attila Darazs 2013-06-25 13:42:26 UTC
Title: Using the Object Storage Service for Image Storage

Describe the issue:

Serious problems I found during trying to follow the instructions on this page.

1) Incorrect setting for swift_store_auth_address. This now points to swift endpoint, when it should point to keystone.

"Set the swift_store_auth_address configuration key to the full authentication URL for your Object Storage deployment. This is the public URL of the Object Storage service entry.

# openstack-config --set /etc/glance/glance-api.conf \
   DEFAULT swift_store_auth_address http://192.0.43.10:8080/v1/"

2) The doc doesn't tell to either create a container in swift for glance, or set the relevant option.

When I corrected error 1), I still got this error message (from /var/log/glance/api.log):
2013-06-25 15:11:58.227 3846 TRACE glance.api.v1.images BackendException: The container glance does not exist in Swift. Please set the swift_store_create_container_on_put option to add container to Swift automatically.


Suggestions for improvement:

1) Config option should point to the keystone endpoint, also fix the ip to "IP":

# openstack-config --set /etc/glance/glance-api.conf \
   DEFAULT swift_store_auth_address http://IP:5000/v2.0


2) Add this option to the config, or tell the user to create the 'glance' container:
# openstack-config --set /etc/glance/glance-api.conf \
   DEFAULT swift_store_create_container_on_put True

This way glance will create a container for its images.

Comment 4 Stephen Gordon 2013-06-27 13:54:29 UTC
(In reply to Attila Darazs from comment #0)
> Title: Using the Object Storage Service for Image Storage
> 
> Describe the issue:
> 
> Serious problems I found during trying to follow the instructions on this
> page.
> 
> 1) Incorrect setting for swift_store_auth_address. This now points to swift
> endpoint, when it should point to keystone.
> 
> "Set the swift_store_auth_address configuration key to the full
> authentication URL for your Object Storage deployment. This is the public
> URL of the Object Storage service entry.
> 
> # openstack-config --set /etc/glance/glance-api.conf \
>    DEFAULT swift_store_auth_address http://192.0.43.10:8080/v1/"
> 
> 2) The doc doesn't tell to either create a container in swift for glance, or
> set the relevant option.
> 
> When I corrected error 1), I still got this error message (from
> /var/log/glance/api.log):
> 2013-06-25 15:11:58.227 3846 TRACE glance.api.v1.images BackendException:
> The container glance does not exist in Swift. Please set the
> swift_store_create_container_on_put option to add container to Swift
> automatically.
> 
> 
> Suggestions for improvement:
> 
> 1) Config option should point to the keystone endpoint, also fix the ip to
> "IP":
> 
> # openstack-config --set /etc/glance/glance-api.conf \
>    DEFAULT swift_store_auth_address http://IP:5000/v2.0

Just looking at this, it looks like the value used in the change was:

DEFAULT swift_store_auth_address http://IP:5000/v2/

Unfortunately v2 is incorrect, it has to be either v2.0 or v3 depending on which Keystone endpoints are available, Keystone only dropped the "minor" number for API versioning when v3 was added in Grizzly (see also Bug # 978657).

Comment 5 Attila Darazs 2013-06-27 15:22:22 UTC
Yes, it should be v2.0; other than that, the changes look good, thank you!

Attila

Comment 6 Summer Long 2013-06-27 22:40:48 UTC
Ok, has been changed to 2.0. Ready for QA with the next doc release.


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