Open Stack

> I think the problem being referred to in this thread is that the backup code
> assumes the *source* is a raw volume. The destination (i.e. swift) should
> absolutely remain universal across all volume back-ends - a JSON list with
> pointers. The JSON file is versioned, so there is scope to add more to it (like we
> did volume metadata), but I don't want to see QCOW or similar going into
> swift.

I agreed with Duncan. I will finish the spec for it within the next few days.

----------
zhangleiqiang (Trump)

Best Regards

> -----Original Message-----
> From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
> Sent: Wednesday, May 28, 2014 9:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup
> 
> On 18 May 2014 12:32, Murali Balcha <Murali.Balcha at triliodata.com> wrote:
> > Hi,
> > I did a design session on Friday though my proposal was to capture the
> > delta as qcow2. Here is the link to ether pad notes.
> >
> > https://etherpad.openstack.org/p/juno-cinder-changed-block-list
> >
> >
> > Do you see synergies between what you are proposing and my proposal?
> > Shouldn¹t we standardize on one format for all backups? I believe
> > Cinder backup API currently uses JSON based list with pointers to all
> > swift objects that make up the backup data of a volume.
> 
> I think the problem being referred to in this thread is that the backup code
> assumes the *source* is a raw volume. The destination (i.e. swift) should
> absolutely remain universal across all volume back-ends - a JSON list with
> pointers. The JSON file is versioned, so there is scope to add more to it (like we
> did volume metadata), but I don't want to see QCOW or similar going into
> swift.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev