Most drivers in Cinder don't deal with local storage rather have a backend storage and an associated api. As an operator, managing multiple backends with Cinder becomes a hassle as each backend requires a single (or more for HA) instance of volume-manager.
This sessions wishes to answer the following and more:
- Who would use it?
- What are the benefits?
- What are the downsides?
- Do the drivers need to change to accomodate this?
- How do we schedule, how to choose the right backend?
- Does scheduling support for this fall under volume_types or a new volume_backend?
Expand on the discussion had on irc and on etherpad on use cases for volume_types and how the drivers / scheduler should handle it. Talk more about metrics the drivers need to expose to the scheduler.
http://etherpad.openstack.org/cinder-usecases
This session will include the following subject(s):
New features:
New features that are too small on their own for a slot on their own:
Secure attach - modifying the attach path to go via a cinder control node before going to the compute node, so that the complete compromise of a compute node does not result in any more volumes being exposed than already happen to be attached to that node.
Retain glance metadata for bootable volumes
https://blueprints.launchpad.net/cinder/+spec/retain-glance-metadata-for-billing
List bootable volumes - proposal for the concept of a bootable volume - purely volume created from glace, for UI easy of design
Volume backup - an API to copy a volume to object store
IOPs meeting / billing
https://blueprints.launchpad.net/cinder/+spec/volume-usage-metering
Volume resize
Volume status state machine (ClayG)
The current volume api needs some TLC. Bringing a volume service to production has helped us identify areas where the current volume API is lacking. I would like to propose that we take a look at what can be done to whip the current volume api in shape to make a v2.0 of the api, and begin discussion of where the api should go down the road.
Rackspace Cloud Block Storage is launching soon. I'd like to describe briefly what the team built, what parts Lunr and OpenStack play in the product, and then dive into some lessons learned in the design and development of a scalable commodity hardware based storage solution and interfacing with nova-volumes, cinder, and the xen storage manager. After that, if anyone is still awake, probably end the talk with a quick wrap up highlighting some of the areas we think OpenStack volumes has the biggest opportunities to improve and with the communities blessing how we can contribute!
The goal of this blueprint is to implement a driver for cinder. This will allow to create volume in local storage and back up point-in-time snapshots of your data to Swift for durable recovery. This snapshots are incremental backups, meaning that only the blocks on the volume that have changed since your last snapshot will be saved.
Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed. So regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.
All in a word, our solutions is local storage + qcow2 image + dependent snapshot + swift. This is like http://wiki.cloudstack.org/display/RelOps/Local+storage+for+data+volumes, but we have incremental snapshot than cloundstack.
If you are interested in this topic, please read the full specification: http://wiki.openstack.org/LocalStorageVolume
Today, OpenStack has support for block-based storage and object storage, but there is no explicit support for file-based storage. For certain applications, file-based storage has significant advantages over block storage and object storage, and a large amount of existing software is designed around file-based storage. We've heard demand from the operator community for a common management interface for file-based storage, and ideally, a common management interface for storage in general. We're proposing adding management of CIFS and NFS file sharing to OpenStack, and we believe that extending Cinder is the most logical way to achieve this, both because Cinder is already in the business of managing storage devices, and because users don’t desire yet another management interface. NetApp has developed a prototype to this end. It includes extended APIs as well as an implementation of a driver backend for Cinder. We'd like to unveil our progress and discuss these with the developer and user communities to see if this approach makes sense, and achieve consensus on a path forward.
