[Gluster-devel] Snapshot CLI question

[Paul Cuzner]

I guess my point about loss of data following a restore boils down to the change of brick names that the restore process "forces". I may be wrong but doesn't this mean that any "downstream" monitoring/scripts have to adjust their idea of what the volume looked like - it just sounds like more work for the admin to me... 

The other thing that wasn't clear from the video, was the impact to fstab. What happens here in relation to the brick name change? 

----- Original Message -----

> From: "Rajesh Joseph" <rjoseph at redhat.com>
> To: "Paul Cuzner" <pcuzner at redhat.com>
> Cc: "gluster-devel" <gluster-devel at nongnu.org>, "Sahina Bose"
> <sabose at redhat.com>
> Sent: Tuesday, 29 April, 2014 10:13:00 PM
> Subject: Re: [Gluster-devel] Snapshot CLI question

> Hi Paul,

> We are thinking of providing policy-driven auto-delete in future. Where user
> can provide various policies by which they can control auto-delete.
> e.g. delete oldest, delete with maximum disk utilization, etc. What you
> mentioned can also be part of the policy.

> Loss of monitoring history has nothing to do with dm-thinp. Monitoring tool
> keeps the history of changes seen by the brick. Now after the restore
> the monitoring tool has no ways to map the newer bricks to the older bricks,
> therefore they discard the history of the older bricks.
> I am sure monitoring team has plans to evolve this and fix this.

> Best Regards,
> Rajesh

> ----- Original Message -----
> From: "Paul Cuzner" <pcuzner at redhat.com>
> To: "Rajesh Joseph" <rjoseph at redhat.com>
> Cc: "gluster-devel" <gluster-devel at nongnu.org>, "Sahina Bose"
> <sabose at redhat.com>
> Sent: Tuesday, April 29, 2014 5:22:42 AM
> Subject: Re: [Gluster-devel] Snapshot CLI question

> No worries, Rajesh.

> Without --xml we're limiting the automation potential and resorting to
> 'screen scraping' - so with that said, is --xml in plan, or do you need an
> RFE?

> Brickpath's changing and loss of history presents an interesting problem for
> monitoring and capacity planning - especially if the data is lost! As an
> admin this would be a real concern. Is this something that will evolve, or
> is this just the flipside of using dm-thinp as the provider for the
> volume/snapshots?

> The other question I raised was around triggers for autodelete. Having a set
> number of snapshots is fine, but I've seen environments in the past where
> autodelete was needed to protect the pool when snapshots deltas were large -
> i.e. autodelete gets triggered at a thinpool freespace threshold.

> Is this last item in the plan? Does it make sense? Does it need an RFE?

> Cheers,

> PC

> ----- Original Message -----

> > From: "Rajesh Joseph" <rjoseph at redhat.com>
> > To: "Paul Cuzner" <pcuzner at redhat.com>
> > Cc: "gluster-devel" <gluster-devel at nongnu.org>, "Sahina Bose"
> > <sabose at redhat.com>
> > Sent: Monday, 28 April, 2014 9:47:04 PM
> > Subject: Re: [Gluster-devel] Snapshot CLI question

> > Sorry Paul for this late reply.

> > As of now we are not supporting --xml option.

> > And restore does change the brick path. Users using their own monitoring
> > script need to be aware of this scenario.
> > RHS monitoring will monitor the new bricks once restored, but the history
> > related to older brick might be lost.

> > Sahin: Would you like to comment on the monitoring part of the question?

> > Thanks & Regards,
> > Rajesh

> > ----- Original Message -----
> > From: "Paul Cuzner" <pcuzner at redhat.com>
> > To: "gluster-devel" <gluster-devel at nongnu.org>
> > Sent: Wednesday, April 23, 2014 5:14:44 AM
> > Subject: [Gluster-devel] Snapshot CLI question

> > Hi,

> > having seen some of the demo's/material around the snapshot cli, it raised
> > a
> > couple of questions;

> > Will --xml be supported?

> > The other question I have relates to brick names. On a demo video I saw the
> > brick names change following a 'restore' operation (i.e. vol info shows
> > different paths - pointing to the paths associated with the snapshot.)

> > Is this the case currently, and if so does this pose a problem for
> > monitoring?

> > Cheers,

> > Paul C

> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140429/8b43228b/attachment-0003.html>