Automatically use minimum size when creating volume from image

[Thomas Herve]

When one creates a volume from a snapshot or another volume, the size argument is calculated automatically. In the case of an image it needs to be specify though, for something larger than the image min_disk attribute. It would be nice to automatically get that size if it's not passed.

[Florent Flament (florentflament)]

John,

I haven't been able to create a volume from a snapshot or another
volume without specifying the new volume's size.

$ cinder create --snapshot-id 5eebad73-420f-4880-9526-333f768a3fc7
...
error: too few arguments
...
$ cinder create --source-volid 4d99648b-f0b1-4276-bf20-bbf09b308dfa
...
error: too few arguments
...

Could you please provide me with the commands that would allow the
automatic computation of a volume's size, when created from a snapshot
or another volume?

When using the "cinder create" command, the feature allowing the
minimum size's automatic computation would have to be implemented in
the 3 scenarios: when creating a volume from a snapshot, an image and
another volume.

[Florent Flament (florentflament)]

I could reproduce the behavior mentioned by John.

When using Cinder's API, through HTTP requests with curl, I can create
new volumes from snapshots or other volumes without specifying the new
volume's size. As said by John, The feature doesn't exist when
creating a volume from an image.

On the other hand, the python-cinderclient doesn't allow to create a
new volume without specifying the volume's size at all.

[Eric Harney (eharney)]

Note that in the review for https://review.openstack.org/#/c/52463/ it was pointed out that Glance doesn't seem to really know the minimum size required unless the image is "raw" format.

So while this sounds like a good idea, I'm a bit concerned about the ability to reliably implement it.

[Florent Flament (florentflament)]

Eric,

Thank you very much for pointing out this issue.

According to my understanding, the issue only happens when trying to create a volume from a qcow2 glance image, because in that case, the image virtual size is different than its physical size.

For other image formats, this distinction (virtual vs physical size) doesn't exist. And according to the review pointed in your last comment (https://review.openstack.org/#/c/52463/), in the case of qcow2 images, we have to consider the image's virtual size to create a volume big enough to accept the image.

I'll take your point into account.

[Juan Manuel Ollé (juan-m-olle)]

Hello,

According to the previous discussion, Is there any reason why cinder-client request the size parameter? In that case it is hidding an API feature.

Do we need do correct the client behaviur?

Thanks

[John Griffith (john-griffith)]

IMO there's a new issue that this has uncovered, not allowing the user to omit the arguments to snapshot and clone from the cinderclient.

The initial posting about calculating the size however is not a bug IMO. The fact is that calculating this may be unreliable, but even more to the point the bigger problem is that if you give a disk that's "just" big enough there's not an awful lot you're going to do with it after creating/boot-up.

It would be valuable to attempt to do some checks before trying to do the image conversion and fail earlier if there's not enough space, but I think the size should be a required parameter here.

[Juan Manuel Ollé (juan-m-olle)]

John,

Do you think that we should create 2 bugs for those 2 problems you mention?

- Optional size parameter for snapshot and clone (cinderclient)
- Checks before image convertion

[Sean McGinnis (sean-mcginnis)]

Closing stale bug. If this is still an issue please reopen.