Open Stack

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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1475 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110719/b46b485a/attachment.bin>