I agree that (1) is the better way to go here.
On Fri, Oct 11, 2013 at 10:50 AM, SuichII, Christopher < chris.su...@netapp.com> wrote: > I'm going to bring the conversation back to this thread since it got > somewhat branched out. > > One hurdle in implementing this is that it has been brought to my > attention that we do not want all snapshots to be revertible. For example, > I believe it is not XenServer best practices to simply revert a snapshot > (in fact, there is no API for it). Instead, XenServer says you should > delete the existing volume, then create a new volume from the snapshot in > its place if you really want to revert. However, the general best practice > is to create a new volume and attach it to the VM instead of reverting. > > So, this means we need some system of determining whether a snapshot can > be reverted in order to show/hide the snapshot accordingly in the UI. If we > don't, then the revert action will always be there, but it will fail unless > the snapshot is actually managed by a storage provider who provides > reverting functionality. Originally I thought about including some > information about whether each volume supports reverting when querying for > volumes. However, I now realize that this should really be done at the > snapshot level because the volume could migrate around primary storage, > leaving snapshots that have been created by different primary storages. > Because of this, I think we should introduce a new interface to > PrimaryDataStoreDrivers, 'canRevert(Snapshot)' to go along with the exiting > 'revertSnapshot(Snapshot)' which would be used when querying for snapshots > to determine whether a snapshot can actually be reverted. > > I see two options with this approach: > 1) Always collect this information when querying for snapshots (like I > described above) > 2) Only load this information when listing actions for a snapshot. > > I prefer (1) since (2) requires a new API to be exposed and (2) only > solves this problem if the end user is using the default CS UI, otherwise > providers creating their own UI would have to query the canRevert API in > their own UI. > > Any thoughts or objections to approach #1? > > -Chris > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 4, 2013, at 6:35 AM, benoit lair <kurushi4...@gmail.com> wrote: > > > This would be very great !! > > > > > > 2013/10/3 Daan Hoogland <daan.hoogl...@gmail.com> > > > >> go go go > >> > >> > >> On Wed, Oct 2, 2013 at 5:07 PM, David Ortiz <dpor...@outlook.com> > wrote: > >> > >>> This sounds like a great idea. > >>> > >>>> From: chiradeep.vit...@citrix.com > >>>> To: dev@cloudstack.apache.org > >>>> Subject: Re: [PROPOSAL] Revert to VM disk Snapshot > >>>> Date: Mon, 30 Sep 2013 21:53:35 +0000 > >>>> > >>>> +1. > >>>> > >>>> On 9/30/13 2:31 PM, "SuichII, Christopher" <chris.su...@netapp.com> > >>> wrote: > >>>> > >>>>> The storage subsystem API currently has an interface for > >> takeSnapshot() > >>>>> and an associated externally facing API for takeSnapshot. There is > >> also > >>> a > >>>>> method on the primary data store interface for revertSnapshot(). > >>> However, > >>>>> this method is unused. We would like this storage subsystem interface > >>>>> method be hooked up to an externally facing API so that we can > provide > >>>>> true VM disk backup and recovery. > >>>>> > >>>>> I will work on formalizing a full functional spec but wanted to get > >> this > >>>>> up for discussion ASAP. > >>>>> > >>>>> I have created a JIRA ticket: > >>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4771 > >>>>> > >>>>> Thanks, > >>>>> Chris > >>>>> -- > >>>>> Chris Suich > >>>>> chris.su...@netapp.com<mailto:chris.su...@netapp.com> > >>>>> NetApp Software Engineer > >>>>> Data Center Platforms Cloud Solutions > >>>>> Citrix, Cisco & Red Hat > >>>>> > >>>> > >>> > >>> > >> > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
