Open Stack

Hi Daniel,
	The intention of image type ('default', 'fast', ' shared', 'sharedfast') look like volume type in cinder. So I think there are two solutions :
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      

 
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


	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.
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've already seen people asking for ability to have a choice of local image backends per flavor even before you raised the SSD idea.
I have seen nova blueprint list, not found any blueprint about this idea, I will register BP and implement this idea.

Thanks.

Zhou Yu


> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Wednesday, April 16, 2014 4:48 PM
> To: Yuzhou (C)
> Cc: openstack-dev at lists.openstack.org; Luohao (brian); Liuji (Jeremy); Bohai
> (ricky)
> Subject: Re: 【openstack-dev】【nova】discussion about add support to SSD
> ephemeral storage
> 
> On Wed, Apr 16, 2014 at 02:17:13AM +0000, Yuzhou (C) wrote:
> > Hi Daniel,
> >
> >      Thanks for your comments about this
> > BP：https://review.openstack.org/#/c/83727/
> >
> >      My initial thoughts is to do little changes then get better
> performance of guest vm. So it is a bit too narrowly focused.
> >
> >      After review SSD use case, I totally agree with your comments. I
> think if I want to implement the broader picture, there are many work items
> that need to do.
> >
> > 1. Add support to create flavor with SSD ephemeral storage.
> >      The cloud adminstrator create the flavor that indicate which
> backend should be used per instance. e.g.
> >           nova flavor-key m1.ssd set
> quota:ephemeral_storage_type=ssd
> > 		 	(root_disk ephemeral_disk and swap_disk are placed onto a
> ssd)
> >      Or more fine grained, e.g.
> >           nova flavor-key m1.ssd set quota:root_disk_type=ssd
> >           nova flavor-key m1.ssd set quota:ephemeral_disk_type=hd
> >           nova flavor-key m1.ssd set quota:swap_disk_type=ssd
> > 			(root_disk and swap_disk are placed onto a ssd,
> ephemeral_disk is
> > placed onto a harddisk)
> 
> I don't think you should be using the term 'ssd' here, or indeed anywhere.
> We should just be letting the admin configure multiple local image types, and
> given them each a name. Then just refer to the image types by name.
> We don't need to care whether they're SSD backed or not - just that the
> admin can configure whatever backends they want to.  I've already seen
> people asking for ability to have a choice of local image backends per flavour
> even before you raised the SSD idea.
> 
> > 2. When config nova,the deployer of openstack configure
> > <ephemeral_storage_pools> e.g.
> >      if libvirt_image_type=default (local disk)
> >           ephemeral_storage_pools=<path1>,<path2>
> >      if  libvirt_image_type=RBD
> >            ephemeral_storage_pools=rdb1,rdb2
> 
> We have to bear in mind existing config parameters:
> 
>   raw/qcow2 - instances_path
>   lvm - images_volume_group
>   rbd -  images_rbd_pool
> 
> I think each of those needs to be extended to allow a list of values, instead
> of a single value.
> 
> Then libvirt_image_type would need to allow a list of names + types eg if we
> wanted to have 2 instances of the raw backend you could perhaps do
> 
>    libvirt_image_type=default:raw, fast:raw
>    instances_path=default:/var/novaimages/hdd,
> fast:/var/nova/images/ssd
> 
> Or if you wanted to do a choice of local qcow2 and two rbd pools, one of
> which is fast ssd backed you could do
> 
>    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
> 
> The tags 'defualt', 'fast', 'shared', 'sharedfast' would be what you'd use in the
> flavour to tag storage.
> 
> 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 :|