Open Stack

On 8/30/2013 12:49 PM, Murali Balcha wrote:
> Hi Caitlin,
> Did you get a chance to look at the wiki? It describes the raksha functionality in detail.
 > It includes more than volume backup. It includes vm images, all
 > volumes and network configurations associated with vms and it
 > supports incremental backups too. Volume backup is essential for
 > implementing backup solution but not necessarily sufficient.

Cinder already allows backing volumes up to Swift, and in fact allows 
incremental backups.

Any code you write will not back up a vendor's volume more efficiently
than the vendor's code itself can.

The vendor's knowledge of how the data is stored is probably sufficient,
but in this case a vendor has a far more powerful advantage. The vendor
can transfer the volume directly to the Swift server. Your service, 
since it running on a compute node rather than the vendor's box, will 
first have to fetch the content and *then* send it to Swift.

That's twice as much network traffic. This is not trivial when volumes
are big, which they tend to be.

If this service is implemented, customer who are using vendor backends
such as NexentaStor, Netapp or CEPH will see their performance drop.
That will clearly be unacceptable. New featqures are not allowed to
trash existing performance, especially when they are not actually
providing any new service to customers who already have volume backends
with these features.

You would need to have a proposal to work with the existing Cinder 
backend Volume Drivers that in no way removed any option vendors have
currently to optimize performance.

Doing that in a new project, rather than within Cinder, can only make
life harder on the vendors and discourage participation in OpenStack.

I believe all of the features you are looking at can be accomodated by
taskflows using the existing Volume Driver feature (as evolving) in 
Cinder.  A new project is not justified, and it will risk creating a
major performance regression for some customers.