Open Stack

On Thu, Apr 17, 2014 at 10:06:03AM +0000, Yuzhou (C) wrote:
> Hi Daniel,
> 	The intention of image type ('default', 'fast', ' shared', 'sharedfast') look like volume
>       type in cinder. So I think there are two solutions :

I was explicitly *NOT* considering those names to be standardized,
because that artifically limits how many different image backends
the admin can setup. I merely used those names as examples - the
site admin should be free to use whatever they decide is most
relevant names to them. Nova shouldn't interpret the image names
in anyway - just treat them as unique "keys" for looking up the
parameters defined in the config/flavour.

> 1. Like using volume type to configure a multiple-storage back-end in cinder, we
> could extend nova API , then create image-type resource to configure a multiple-image
> back-end in nova.

> 	e.g.
> 		in nova.conf,
>     		libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd, sharedfast:rbd
>     		instance_path=default:/var/nova/images/hdd, fast:/var/nova/imges/ssd
>     		images_rbd_pool=shared:main,sharedfast:mainssd
> 
> 		nova image-type-create normal_image
>         nova image-type-key normal_image root_disk_type=default
>         nova image-type-key normal_image ephemeral _disk_type=default 
>         nova image-type-key normal_image swap_disk_type=default  
> 
> 		nova image-type-create fast_image
>         nova image-type-key fast_image root_disk_type=fast
>         nova image-type-key fast_image ephemeral _disk_type=default 
>         nova image-type-key fast_image swap_disk_type=fast   
> 
> 		nova flavor-key m3.xlarge set quota:image-type= fast_image      

This concept shouldn't be tied to cinder in any way. This is purely something
for nova to be concerned with.


> 
>  
> 2. Like our discussion in mails, image types are defined in configuration file, enumerated type, ie set <libvirt_image_type> in nova.conf
> 	e.g.
> 		in nova.conf,
>     		libvirt_image_type=default:qcow2, fast:qcow2, shared:rbd, sharedfast:rbd
>     		instance_path=default:/var/nova/images/hdd, fast:/var/nova/imges/ssd
>     		images_rbd_pool=shared:main,sharedfast:mainssd
> 
> 		nova flavor0key m3.xlarge set ephemeral_storage_type =fast
> 		or more fine grained,
> 		nova flavor-key m3.xlarge set quota:root_disk_type=fast
> 		nova flavor-key m3.xlarge set quota:ephemeral_disk_type=default
> 		nova flavor-key m3.xlarge set quota:swap_disk_type=fast

This one is what I'd prefer.

> 
> 
> 	Which solution do you prefer?
> 
> 	If you prefer second solution, I think better to set
>  <libvirt_image_type> like this: libvirt_image_type=default:raw:HDD,
> fast:raw:SSD *fast* means what, I think only the deployer of openstack
> knows clearly. So description field would be need. "HDD" and "SSD" are
> the description of image type name.

I don't really see a need for the extra description here. 

> Maybe in second solution, we would not need to create/delete
> image-type resource, but I think the api about listing image-types
> is needed. Do you think so?

I guess there could be a need for a way to list image types so the
person defining flavours knows what the host admin has made available
to them.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|