[Openstack] Glance API semantics when image sizes aren't known

Ewan Mellor Ewan.Mellor at eu.citrix.com
Tue Nov 15 22:17:10 UTC 2011


> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
>
> >> On upload, once an image file is successfully uploaded to the
> backend
> >> store, Glance will set the image's size to the number of bytes that
> >> the backend store reported that it wrote.
> >>
> >> On uploading an image when Swift is the backing store, Glance does
> its
> >> best to upload the image file if no Content-Length or
> >> X-Image-Meta-Size is specified, but on the event of a failed Swift
> >> upload, the image size does not get set.
> >
> > It also does not set the image size if the upload is successful.
> > image_size is returned unchanged from glance.store.swift.Store.add,
> so
> > 0 is passed in, and passed out again.
> >
> > So the question is whether this is a bug.  Are you expecting the
> > backend to return a correct image size if the upload is successful?
> 
> Absolutely. If it's not, that's a bug.

OK, I'll file a bug.

> >> > Because the docs imply that the size will be inferred from the
> body
> >> of the upload request, but that's not what is happening in the Swift
> >> backend.
> >>
> >> Would it be possible to paste the code you are using to do the
> upload?
> >
> > ~ # cat test_glance.py
> > import sys
> > import glance.client
> >
> > client = glance.client.Client('localhost', 9292,
> auth_tok="999888777666")
> > print client.add_image({}, sys.stdin)
> > ~ # echo a | python26 ./test_glance.py
> > {u'status': u'active', u'name': None, u'deleted': False,
> u'container_format': None, u'created_at': u'2011-11-15T21:44:21',
> u'disk_format': None, u'updated_at': u'2011-11-15T21:44:22', u'id': 6,
> u'owner': u'Administrator', u'location':
> u'swift+http://root:password@localhost:5000/v1.0/glance/6', u'min_ram':
> 0, u'checksum': u'60b725f10c9c85c70d97880dfe8191b3', u'min_disk': 0,
> u'is_public': False, u'deleted_at': None, u'properties': {}, u'size':
> 0}
> >
> > Note that size is returned as 0, not 1.
> 
> Yes, indeed. That is because the client is not designed to be used
> that way [snip]

But it could perfectly well be used this way, modulo the bug above, and
this is a very useful thing to be able to do (stdin here could be a
decompression or decryption pipeline, or a read from a remote socket, or
whatever.

With the bug in the Swift backend fixed, I think it will work just fine
to stream through a glance client in this way.

Cheers,

Ewan.



More information about the Openstack mailing list