Chuck,

This is very welcome in light of LUNR's refactoring.  The first concept 
outlined was supported by an example of differing performance tiers.  I'd 
elaborate by indicating that classes of storage can be defined on the basis of 
performance (which itself is nuanced: latency, throughput, IOP/s), protection 
policies, availability, is it cached, cloned, deduplicated, compressed, 
encrypted, et cetera?  Nova volume needs to support some notion of those 
characteristics as well.
Thanks,
Rob Esker


On Jul 18, 2011, at 6:05 PM, Chuck Thier wrote:

> There are two concepts that I would like Nova Volumes to support:
> 
> 1.  Allow different storage classes within a storage driver.  For
> example, in our case we will have some nodes with high iops
> capabilities and other nodes for cheaper/larger  volumes.
> 
> 2.  Allow for different storage backends to be used and specified by
> the user.  For example, you might want to use both the Lunr volume
> backend, and one of the SAN backends.
> 
> I think having the idea of a volume type when creating a volume would
> support both of these features.  I have started a blueprint and spec
> below, and would like to solicit feedback.
> 
> Blueprint: https://blueprints.launchpad.net/nova/+spec/volume-type
> Spec: http://etherpad.openstack.org/volume-type
> 
> Please let me know what you think, and if you have any questions.
> 
> --
> Chuck
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to