Open Stack

Hi murali,

A question I am wondering,

How much of the rashka code exists? It looks like from the design docs that a lot of it might be working already?? 

I do understand and wonder what u think about what caitlin stated and how/if rashka will solve these types of "overlap" issues (especially the part about rashka not having the same access to the underlying volume "semantics" that cinder would have access to and the effects this would have on rashka). In general I think the new project is a neat idea, and it will be interesting to see what happens. 

I think I saw taskflow mentioned somewhere in the wiki or this thread so feel free to jump on irc with any questions. :)

Sent from my really tiny device...

On Aug 30, 2013, at 9:27 PM, "Caitlin Bestler" <caitlin.bestler at nexenta.com> wrote:

> 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.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev