Bug 977866

Summary:	Bad instructions for setting up glance for swift storage
Product:	Red Hat OpenStack	Reporter:	Attila Darazs <adarazs>
Component:	doc-Installation_and_Configuration_Guide	Assignee:	Summer Long <slong>
Status:	CLOSED CURRENTRELEASE	QA Contact:	ecs-bugs
Severity:	high	Docs Contact:
Priority:	high
Version:	3.0	CC:	adarazs, hateya, sgordon, slong
Target Milestone:	---	Keywords:	Documentation
Target Release:	4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
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	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1011085

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.