What is the plan for uploading tarballs?

Asked by David Kranz on 2012-01-13

It seems that you can upload *.tar.gz machine images into glance using uec-publish-tarball (now cloud-publish-tarball) and they can be booted without difficulty. But 'nova image-show' will then display them with no name making that feature useless. stack.sh unpacks the tarball and uses the glance api to upload the individual pieces giving them names that will be displayed, but that seems unnecessarily cumbersome. It would be nice if the glance cli had a way to upload such a bundle and give it a name. Failing that, it would be nice if glance defaulted the case of 'name=Null' to some other metadata info, perhaps the leaf of the image_location. Am I missing something?

Question information

English Edit question
Glance Edit question
No assignee Edit question
Solved by:
Jay Pipes
Last query:
Last reply:
Jay Pipes (jaypipes) said : #1

Hi David! Hope all is well in this New Year! :)

To answer your question, it's important to understand that uec-publish-tarball does *not* actually upload the tarball to Glance. What actually happens is that uec-publish-tarball is communicating with the nova-api endpoint, on the EC2 API controller, and the controller is communicating with both Glance *and* nova-objectstore, which acts as the (required by uec-publish-tarball) S3 service that is used to store things like the manifest.xml and image part files. Once the tarball is unpacked and the contents decrypted, the final uncompressed, decrypted disk image file is what is uploaded to Glance.

You are correct that stack.sh unpacks a tarball (with a cirros ramdisk, kernel and disk image) by default and uses the glance CLI tool to upload each piece to Glance in devstack. However, the only image you can actually use in Horizon to build a server instance is the disk image, so it's kind of silly listing the kernel and ramdisk images since you cannot (currently at least) boot an instance in Horizon or the Compute API by specifying a ramdisk, kernel and/or filesystem image separately. At least, that's AFAIK...

Finally, per your assertion that Glance should set name = image_location if name is None, I think that's an admirable idea. Unfortunately, though, the location field is not actually editable or viewable after being set by Glance (since it can contain security credentials -- for instance, for logging into a swift backend cluster providing actual storage to Glance).

That said, I'm not opposed to defaulting name to the UUID of the image if no name was specified... would that work?


David Kranz (david-kranz) said : #2

Thanks, Jay. I am not sure exactly what the UUID is but if it is a "random" hex string it would not be that helpful. Even though you can only boot one of the images that devstack uploads, devstack uses the kernel-id from uploading the kernel as an argument to the upload for the image so I assumed that was necessary.

 There are many of these images published and I don't think users should have to understand how the system processes them in order to upload them to glance and then boot with them. All I am really looking for is a command, in some openstack cli, that allows you to upload a uec "image" such that it shows up in glance with a name that means something to a user. Until then, I guess I can pull the devstack code into a script and use that.

Jay Pipes (jaypipes) said : #3

I guess I'm not really understanding the request, then...

The glance CLI tool and client allows the user to set the name of the image. If something is calling the glance CLI tool or client and not providing a relevant name for the image, isn't that the domain of the calling script, not Glance's problem?


David Kranz (david-kranz) said : #4

I'm sorry for being unclear.

Is there an easier way for a user to upload tarballs with names for use by nova than the method used in devstack and, if not, should there be?

Best Jay Pipes (jaypipes) said : #5

David, devstack isn't uploading tarballs to Glance... it is manually untar'ing a tarball and adding the kernel and ramdisk images included in the UEC-style tarball, and then manually uncompressing the disk image contained in the tarball and adding that to glance along with the kernel_id and ramdisk_id custom properties set to the UUIDs generated by glance for the kernel and ramdisk images.

Technically, adding the kernel and ramdisk is entirely optional and AFAICT, is only done because Horizon's "edit image" form includes fields for kernel and ramdisk IDs because Horizon was originally an EC2 API only thing and kernel and ramdisk only really makes sense in the EC2 world. When you call euca-describe-images, the kernel and ramdisk custom properties that are stored in Glance are displayed.


David Kranz (david-kranz) said : #6

OK, thanks. I don't know that much about vm image formats and such. I was trying to move away from euca-* and use the nova/glance cli instead. I hope that is the right thing to do...

David Kranz (david-kranz) said : #7

Thanks Jay Pipes, that solved my question.

David Kranz (david-kranz) said : #8

Jay, it seems that your description of what uec-publish-tarball does is not quite right: it uploads *both* the image file and the kernel file to glance. I verified that just uploading the .img file does not work. nova gives an error saying it cannot find the kernel.

Jay Pipes (jaypipes) said : #9

Hmm, interesting... I did not know that... alright, lemme look further into this and see what the deal is. I don't really understand how this is the case since you do not need to supply a kernel when starting things other than an AMI-style image.