Bug 888537 - glance --location has no effect
Summary: glance --location has no effect
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-glance
Version: 2.0 (Folsom)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact: Yaniv Kaul
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-18 20:43 UTC by John Bresnahan
Modified: 2013-09-30 02:04 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-21 17:03:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description John Bresnahan 2012-12-18 20:43:08 UTC
Description of problem:

The glance CLI program offers the option --location to image-create.  The following is the output of "glance help image-create":

  --location <IMAGE_URL>
                        URL where the data for this image already resides. For
                        example, if the image data is stored in the filesystem
                        local to the glance server at
                        '/usr/share/image.tar.gz', you would specify
                        'file:///usr/share/image.tar.gz'.

This implies that a URL can be passed into glance and this will be the location of the image, rather than having the image uploaded.  However, glance rejects any URL type other than http{s}, including file:/.

When http{s} is used the command succeeds, however it is not retained in the information associated with the the image in the registry.  A sample session follows:


$ glance  image-create  --name testit --container-format bare --disk-format qcow2 --is-public true --location file:///helloworld 
Request returned failure status.
HTTPBadRequest (HTTP 400)

$ glance  image-create  --name testit --container-format bare --disk-format qcow2 --is-public true --location http://localhost/test
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | None                                 |
| container_format | bare                                 |
| created_at       | 2012-12-18T19:57:22                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 009ef1cf-9e7a-4ec7-aa4d-d179c0a9a2c5 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | testit                               |
| owner            | fc44c2c6815b4018a861f9e455b260e7     |
| protected        | False                                |
| size             | 0                                    |
| status           | active                               |
| updated_at       | 2012-12-18T19:57:22                  |
+------------------+--------------------------------------+
$ glance show 009ef1cf-9e7a-4ec7-aa4d-d179c0a9a2c5
URI: http://127.0.0.1:9292/v1/images/009ef1cf-9e7a-4ec7-aa4d-d179c0a9a2c5
Id: 009ef1cf-9e7a-4ec7-aa4d-d179c0a9a2c5
Public: Yes
Protected: No
Name: testit
Status: active
Size: 0
Disk format: qcow2
Container format: bare
Minimum Ram Required (MB): 0
Minimum Disk Required (GB): 0
Owner: fc44c2c6815b4018a861f9e455b260e7
Created at: 2012-12-18T19:57:22
Updated at: 2012-12-18T19:57:22



Expected results:

I expected to see the passed in URL maintained an listed with as the URI.

Comment 2 Eoghan Glynn 2012-12-18 21:17:53 UTC
Hi John,

This mainly looks like expected behavior.

Local external sources are deliberately not supported to avoid the obvious security vulnerability:

  glance image-create --location file:///etc/passwd ...

Have you tried with s3:// or swift:// URIs?

Also the fact that a different URL is associated with the image resource is expected, because in the v1 glance API image metadata is retrieved by HEADing this URL - clearly the external location URL would not be suitable for returning these metadata as response headers. Hence the need for a distinguished image URL serviced by glance, in addition to the external location.

Not necessarily saying there isn't a bug lurking here somewhere (certainly the CLI could do better than a bare HTTPBadRequest error message), but most of what you've described is the kind of behaviour I'd expect.

Cheers,
Eoghan

Comment 3 Eoghan Glynn 2012-12-21 17:03:40 UTC
As explained above, I think this is all behaving as intended, so closing as NOTABUG.

John, please free to re-open if appropriate.


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