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 :|
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
