Re: [Gluster-devel] autodelete in snapshots
On Wednesday 04 June 2014 11:23 AM, Rajesh Joseph wrote: - Original Message - From: "M S Vishwanath Bhat" To: "Rajesh Joseph" Cc: "Vijay Bellur" , "Seema Naik" , "Gluster Devel" Sent: Tuesday, June 3, 2014 5:55:27 PM Subject: Re: [Gluster-devel] autodelete in snapshots On 3 June 2014 15:21, Rajesh Joseph wrote: - Original Message - From: "M S Vishwanath Bhat" To: "Vijay Bellur" Cc: "Seema Naik" , "Gluster Devel" < gluster-devel@gluster.org> Sent: Tuesday, June 3, 2014 1:02:08 AM Subject: Re: [Gluster-devel] autodelete in snapshots On 2 June 2014 20:22, Vijay Bellur < vbel...@redhat.com > wrote: On 04/23/2014 05:50 AM, Vijay Bellur wrote: On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: On 04/16/2014 11:39 AM, Avra Sengupta wrote: The whole purpose of introducing the soft-limit is, that at any point of time the number of snaps should not exceed the hard limit. If we trigger auto-delete on hitting hard-limit, then the purpose itself is lost, because at that point we would be taking a snap, making the limit hard-limit + 1, and then triggering auto-delete, which violates the sanctity of the hard-limit. Also what happens when we are at hard-limit + 1, and another snap is issued, while auto-delete is yet to process the first delete. At that point we end up at hard-limit + 1. Also what happens if for a particular snap the auto-delete fails. We should see the hard-limit, as something set by the admin keeping in mind the resource consumption and at no-point should we cross this limit, come what may. If we hit this limit, the create command should fail asking the user to delete snaps using the "snapshot delete" command. The two options Raghavendra mentioned are applicable for the soft-limit only, in which cases on hitting the soft-limit 1. Trigger auto-delete or 2. Log a warning-message, for the user saying the number of snaps is exceeding the snap-limit and display the number of available snaps Now which of these should happen also depends on the user, because the auto-delete option is configurable. So if the auto-delete option is set as true, auto-delete should be triggered and the above message should also be logged. But if the option is set as false, only the message should be logged. This is the behaviour as designed. Adding Rahul, and Seema in the mail, to reflect upon the behaviour as well. Regards, Avra This sounds correct. However we need to make sure that the usage or documentation around this should be good enough , so that users understand the each of the limits correctly. It might be better to avoid the usage of the term "soft-limit". soft-limit as used in quota and other places generally has an alerting connotation. Something like "auto-deletion-limit" might be better. I still see references to "soft-limit" and auto deletion seems to get triggered upon reaching soft-limit. Why is the ability to auto delete not configurable? It does seem pretty nasty to go about deleting snapshots without obtaining explicit consent from the user. I agree with Vijay here. It's not good to delete a snap (even though it is oldest) without the explicit consent from user. FYI It took me more than 2 weeks to figure out that my snaps were getting autodeleted after reaching "soft-limit". For all I know I had not done anything and my snap restore were failing. I propose to remove the terms "soft" and "hard" limit. I believe there should be a limit (just "limit") after which all snapshot creates should fail with proper error messages. And there can be a water-mark after which user should get warning messages. So below is my proposal. auto-delete + snap-limit: If the snap-limit is set to n , next snap create (n+1th) will succeed only if if auto-delete is set to on/true/1 and oldest snap will get deleted automatically. If autodelete is set to off/false/0 , (n+1)th snap create will fail with proper error message from gluster CLI command. But again by default autodelete should be off. snap-water-mark : This should come in picture only if autodelete is turned off. It should not have any meaning if auto-delete is turned ON. Basically it's usage is to give the user warning that limit almost being reached and it is time for admin to decide which snaps should be deleted (or which should be kept) *my two cents* -MS The reason for having a hard-limit is to stop snapshot creation once we reached this limit. This helps to have a control over the resource consumption. Therefore if we only have this limit (as snap-limit) then there is no question of auto-delete. Auto-delete can only be triggered once the count crosses the limit. Therefore we introduced the concept of soft-limit and a hard-limit. As the name suggests once the hard-limit is reached no more snaps will be created. Per
Re: [Gluster-devel] autodelete in snapshots
- Original Message - > From: "M S Vishwanath Bhat" > To: "Rajesh Joseph" > Cc: "Vijay Bellur" , "Seema Naik" , > "Gluster Devel" > > Sent: Tuesday, June 3, 2014 5:55:27 PM > Subject: Re: [Gluster-devel] autodelete in snapshots > > On 3 June 2014 15:21, Rajesh Joseph wrote: > > > > > > > - Original Message - > > From: "M S Vishwanath Bhat" > > To: "Vijay Bellur" > > Cc: "Seema Naik" , "Gluster Devel" < > > gluster-devel@gluster.org> > > Sent: Tuesday, June 3, 2014 1:02:08 AM > > Subject: Re: [Gluster-devel] autodelete in snapshots > > > > > > > > > > On 2 June 2014 20:22, Vijay Bellur < vbel...@redhat.com > wrote: > > > > > > > > On 04/23/2014 05:50 AM, Vijay Bellur wrote: > > > > > > On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: > > > > > > On 04/16/2014 11:39 AM, Avra Sengupta wrote: > > > > > > The whole purpose of introducing the soft-limit is, that at any point > > of time the number of > > snaps should not exceed the hard limit. If we trigger auto-delete on > > hitting hard-limit, then > > the purpose itself is lost, because at that point we would be taking a > > snap, making the limit > > hard-limit + 1, and then triggering auto-delete, which violates the > > sanctity of the hard-limit. > > Also what happens when we are at hard-limit + 1, and another snap is > > issued, while auto-delete > > is yet to process the first delete. At that point we end up at > > hard-limit + 1. Also what happens > > if for a particular snap the auto-delete fails. > > > > We should see the hard-limit, as something set by the admin keeping in > > mind the resource consumption > > and at no-point should we cross this limit, come what may. If we hit > > this limit, the create command > > should fail asking the user to delete snaps using the "snapshot > > delete" command. > > > > The two options Raghavendra mentioned are applicable for the > > soft-limit only, in which cases on > > hitting the soft-limit > > > > 1. Trigger auto-delete > > > > or > > > > 2. Log a warning-message, for the user saying the number of snaps is > > exceeding the snap-limit and > > display the number of available snaps > > > > Now which of these should happen also depends on the user, because the > > auto-delete option > > is configurable. > > > > So if the auto-delete option is set as true, auto-delete should be > > triggered and the above message > > should also be logged. > > > > But if the option is set as false, only the message should be logged. > > > > This is the behaviour as designed. Adding Rahul, and Seema in the > > mail, to reflect upon the > > behaviour as well. > > > > Regards, > > Avra > > > > This sounds correct. However we need to make sure that the usage or > > documentation around this should be good enough , so that users > > understand the each of the limits correctly. > > > > > > It might be better to avoid the usage of the term "soft-limit". > > soft-limit as used in quota and other places generally has an alerting > > connotation. Something like "auto-deletion-limit" might be better. > > > > > > I still see references to "soft-limit" and auto deletion seems to get > > triggered upon reaching soft-limit. > > > > Why is the ability to auto delete not configurable? It does seem pretty > > nasty to go about deleting snapshots without obtaining explicit consent > > from the user. > > > > I agree with Vijay here. It's not good to delete a snap (even though it is > > oldest) without the explicit consent from user. > > > > FYI It took me more than 2 weeks to figure out that my snaps were getting > > autodeleted after reaching "soft-limit". For all I know I had not done > > anything and my snap restore were failing. > > > > I propose to remove the terms "soft" and "hard" limit. I believe there > > should be a limit (just "limit") after which all snapshot creates should > > fail with proper error messages. And there can be a water-mark after which > > user should get warning messages. So below is my proposal. > > > > auto-delete + snap-limit: If the snap-limit is set to n , next snap create > > (n+1th) will succeed only if if auto-delete is set to on/true/1 a
Re: [Gluster-devel] autodelete in snapshots
On 3 June 2014 15:21, Rajesh Joseph wrote: > > > - Original Message - > From: "M S Vishwanath Bhat" > To: "Vijay Bellur" > Cc: "Seema Naik" , "Gluster Devel" < > gluster-devel@gluster.org> > Sent: Tuesday, June 3, 2014 1:02:08 AM > Subject: Re: [Gluster-devel] autodelete in snapshots > > > > > On 2 June 2014 20:22, Vijay Bellur < vbel...@redhat.com > wrote: > > > > On 04/23/2014 05:50 AM, Vijay Bellur wrote: > > > On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: > > > On 04/16/2014 11:39 AM, Avra Sengupta wrote: > > > The whole purpose of introducing the soft-limit is, that at any point > of time the number of > snaps should not exceed the hard limit. If we trigger auto-delete on > hitting hard-limit, then > the purpose itself is lost, because at that point we would be taking a > snap, making the limit > hard-limit + 1, and then triggering auto-delete, which violates the > sanctity of the hard-limit. > Also what happens when we are at hard-limit + 1, and another snap is > issued, while auto-delete > is yet to process the first delete. At that point we end up at > hard-limit + 1. Also what happens > if for a particular snap the auto-delete fails. > > We should see the hard-limit, as something set by the admin keeping in > mind the resource consumption > and at no-point should we cross this limit, come what may. If we hit > this limit, the create command > should fail asking the user to delete snaps using the "snapshot > delete" command. > > The two options Raghavendra mentioned are applicable for the > soft-limit only, in which cases on > hitting the soft-limit > > 1. Trigger auto-delete > > or > > 2. Log a warning-message, for the user saying the number of snaps is > exceeding the snap-limit and > display the number of available snaps > > Now which of these should happen also depends on the user, because the > auto-delete option > is configurable. > > So if the auto-delete option is set as true, auto-delete should be > triggered and the above message > should also be logged. > > But if the option is set as false, only the message should be logged. > > This is the behaviour as designed. Adding Rahul, and Seema in the > mail, to reflect upon the > behaviour as well. > > Regards, > Avra > > This sounds correct. However we need to make sure that the usage or > documentation around this should be good enough , so that users > understand the each of the limits correctly. > > > It might be better to avoid the usage of the term "soft-limit". > soft-limit as used in quota and other places generally has an alerting > connotation. Something like "auto-deletion-limit" might be better. > > > I still see references to "soft-limit" and auto deletion seems to get > triggered upon reaching soft-limit. > > Why is the ability to auto delete not configurable? It does seem pretty > nasty to go about deleting snapshots without obtaining explicit consent > from the user. > > I agree with Vijay here. It's not good to delete a snap (even though it is > oldest) without the explicit consent from user. > > FYI It took me more than 2 weeks to figure out that my snaps were getting > autodeleted after reaching "soft-limit". For all I know I had not done > anything and my snap restore were failing. > > I propose to remove the terms "soft" and "hard" limit. I believe there > should be a limit (just "limit") after which all snapshot creates should > fail with proper error messages. And there can be a water-mark after which > user should get warning messages. So below is my proposal. > > auto-delete + snap-limit: If the snap-limit is set to n , next snap create > (n+1th) will succeed only if if auto-delete is set to on/true/1 and oldest > snap will get deleted automatically. If autodelete is set to off/false/0 , > (n+1)th snap create will fail with proper error message from gluster CLI > command. But again by default autodelete should be off. > > snap-water-mark : This should come in picture only if autodelete is turned > off. It should not have any meaning if auto-delete is turned ON. Basically > it's usage is to give the user warning that limit almost being reached and > it is time for admin to decide which snaps should be deleted (or which > should be kept) > > *my two cents* > > -MS > > > The reason for having a hard-limit is to stop snapshot creation once we > reached this limit. This helps to have a control over the resource > consumption. Therefore if we only have this limit (as snap-limit) then > there is no q
Re: [Gluster-devel] autodelete in snapshots
- Original Message - From: "M S Vishwanath Bhat" To: "Vijay Bellur" Cc: "Seema Naik" , "Gluster Devel" Sent: Tuesday, June 3, 2014 1:02:08 AM Subject: Re: [Gluster-devel] autodelete in snapshots On 2 June 2014 20:22, Vijay Bellur < vbel...@redhat.com > wrote: On 04/23/2014 05:50 AM, Vijay Bellur wrote: On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: On 04/16/2014 11:39 AM, Avra Sengupta wrote: The whole purpose of introducing the soft-limit is, that at any point of time the number of snaps should not exceed the hard limit. If we trigger auto-delete on hitting hard-limit, then the purpose itself is lost, because at that point we would be taking a snap, making the limit hard-limit + 1, and then triggering auto-delete, which violates the sanctity of the hard-limit. Also what happens when we are at hard-limit + 1, and another snap is issued, while auto-delete is yet to process the first delete. At that point we end up at hard-limit + 1. Also what happens if for a particular snap the auto-delete fails. We should see the hard-limit, as something set by the admin keeping in mind the resource consumption and at no-point should we cross this limit, come what may. If we hit this limit, the create command should fail asking the user to delete snaps using the "snapshot delete" command. The two options Raghavendra mentioned are applicable for the soft-limit only, in which cases on hitting the soft-limit 1. Trigger auto-delete or 2. Log a warning-message, for the user saying the number of snaps is exceeding the snap-limit and display the number of available snaps Now which of these should happen also depends on the user, because the auto-delete option is configurable. So if the auto-delete option is set as true, auto-delete should be triggered and the above message should also be logged. But if the option is set as false, only the message should be logged. This is the behaviour as designed. Adding Rahul, and Seema in the mail, to reflect upon the behaviour as well. Regards, Avra This sounds correct. However we need to make sure that the usage or documentation around this should be good enough , so that users understand the each of the limits correctly. It might be better to avoid the usage of the term "soft-limit". soft-limit as used in quota and other places generally has an alerting connotation. Something like "auto-deletion-limit" might be better. I still see references to "soft-limit" and auto deletion seems to get triggered upon reaching soft-limit. Why is the ability to auto delete not configurable? It does seem pretty nasty to go about deleting snapshots without obtaining explicit consent from the user. I agree with Vijay here. It's not good to delete a snap (even though it is oldest) without the explicit consent from user. FYI It took me more than 2 weeks to figure out that my snaps were getting autodeleted after reaching "soft-limit". For all I know I had not done anything and my snap restore were failing. I propose to remove the terms "soft" and "hard" limit. I believe there should be a limit (just "limit") after which all snapshot creates should fail with proper error messages. And there can be a water-mark after which user should get warning messages. So below is my proposal. auto-delete + snap-limit: If the snap-limit is set to n , next snap create (n+1th) will succeed only if if auto-delete is set to on/true/1 and oldest snap will get deleted automatically. If autodelete is set to off/false/0 , (n+1)th snap create will fail with proper error message from gluster CLI command. But again by default autodelete should be off. snap-water-mark : This should come in picture only if autodelete is turned off. It should not have any meaning if auto-delete is turned ON. Basically it's usage is to give the user warning that limit almost being reached and it is time for admin to decide which snaps should be deleted (or which should be kept) *my two cents* -MS The reason for having a hard-limit is to stop snapshot creation once we reached this limit. This helps to have a control over the resource consumption. Therefore if we only have this limit (as snap-limit) then there is no question of auto-delete. Auto-delete can only be triggered once the count crosses the limit. Therefore we introduced the concept of soft-limit and a hard-limit. As the name suggests once the hard-limit is reached no more snaps will be created. So the idea is to keep the number of snapshots always less than the hard-limit. To do so we introduced the concept of soft-limit, wherein we allow snapshots even when this limit is crossed and once the snapshot is taken we delete the oldest snap. If you consider this definition then the name soft-limit and hard-limit looks ok to me. I
Re: [Gluster-devel] autodelete in snapshots
I agree as well. We shouldn't be deleting any data without the explicit consent of the user. The approach proposed by MS is better than the earlier approach. ~kaushal On Tue, Jun 3, 2014 at 1:02 AM, M S Vishwanath Bhat wrote: > > > > On 2 June 2014 20:22, Vijay Bellur wrote: >> >> On 04/23/2014 05:50 AM, Vijay Bellur wrote: >>> >>> On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: On 04/16/2014 11:39 AM, Avra Sengupta wrote: > > The whole purpose of introducing the soft-limit is, that at any point > of time the number of > snaps should not exceed the hard limit. If we trigger auto-delete on > hitting hard-limit, then > the purpose itself is lost, because at that point we would be taking a > snap, making the limit > hard-limit + 1, and then triggering auto-delete, which violates the > sanctity of the hard-limit. > Also what happens when we are at hard-limit + 1, and another snap is > issued, while auto-delete > is yet to process the first delete. At that point we end up at > hard-limit + 1. Also what happens > if for a particular snap the auto-delete fails. > > We should see the hard-limit, as something set by the admin keeping in > mind the resource consumption > and at no-point should we cross this limit, come what may. If we hit > this limit, the create command > should fail asking the user to delete snaps using the "snapshot > delete" command. > > The two options Raghavendra mentioned are applicable for the > soft-limit only, in which cases on > hitting the soft-limit > > 1. Trigger auto-delete > > or > > 2. Log a warning-message, for the user saying the number of snaps is > exceeding the snap-limit and > display the number of available snaps > > Now which of these should happen also depends on the user, because the > auto-delete option > is configurable. > > So if the auto-delete option is set as true, auto-delete should be > triggered and the above message > should also be logged. > > But if the option is set as false, only the message should be logged. > > This is the behaviour as designed. Adding Rahul, and Seema in the > mail, to reflect upon the > behaviour as well. > > Regards, > Avra This sounds correct. However we need to make sure that the usage or documentation around this should be good enough , so that users understand the each of the limits correctly. >>> >>> It might be better to avoid the usage of the term "soft-limit". >>> soft-limit as used in quota and other places generally has an alerting >>> connotation. Something like "auto-deletion-limit" might be better. >>> >> >> I still see references to "soft-limit" and auto deletion seems to get >> triggered upon reaching soft-limit. >> >> Why is the ability to auto delete not configurable? It does seem pretty >> nasty to go about deleting snapshots without obtaining explicit consent from >> the user. > > > I agree with Vijay here. It's not good to delete a snap (even though it is > oldest) without the explicit consent from user. > > FYI It took me more than 2 weeks to figure out that my snaps were getting > autodeleted after reaching "soft-limit". For all I know I had not done > anything and my snap restore were failing. > > I propose to remove the terms "soft" and "hard" limit. I believe there > should be a limit (just "limit") after which all snapshot creates should > fail with proper error messages. And there can be a water-mark after which > user should get warning messages. So below is my proposal. > > auto-delete + snap-limit: If the snap-limit is set to n, next snap create > (n+1th) will succeed only if if auto-delete is set to on/true/1 and oldest > snap will get deleted automatically. If autodelete is set to off/false/0 , > (n+1)th snap create will fail with proper error message from gluster CLI > command. But again by default autodelete should be off. > > snap-water-mark: This should come in picture only if autodelete is turned > off. It should not have any meaning if auto-delete is turned ON. Basically > it's usage is to give the user warning that limit almost being reached and > it is time for admin to decide which snaps should be deleted (or which > should be kept) > > *my two cents* > > -MS > >> >> >> Cheers, >> >> Vijay >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] autodelete in snapshots
+rajesh - Original Message - > From: "M S Vishwanath Bhat" > To: "Vijay Bellur" > Cc: "Lalatendu Mohanty" , "Avra Sengupta" > , "Raghavendra Bhat" > , "Gluster Devel" , "Rahul > Hinduja" , "Seema > Naik" > Sent: Tuesday, June 3, 2014 1:02:08 AM > Subject: Re: [Gluster-devel] autodelete in snapshots > > On 2 June 2014 20:22, Vijay Bellur wrote: > > > On 04/23/2014 05:50 AM, Vijay Bellur wrote: > > > >> On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: > >> > >>> On 04/16/2014 11:39 AM, Avra Sengupta wrote: > >>> > >>>> The whole purpose of introducing the soft-limit is, that at any point > >>>> of time the number of > >>>> snaps should not exceed the hard limit. If we trigger auto-delete on > >>>> hitting hard-limit, then > >>>> the purpose itself is lost, because at that point we would be taking a > >>>> snap, making the limit > >>>> hard-limit + 1, and then triggering auto-delete, which violates the > >>>> sanctity of the hard-limit. > >>>> Also what happens when we are at hard-limit + 1, and another snap is > >>>> issued, while auto-delete > >>>> is yet to process the first delete. At that point we end up at > >>>> hard-limit + 1. Also what happens > >>>> if for a particular snap the auto-delete fails. > >>>> > >>>> We should see the hard-limit, as something set by the admin keeping in > >>>> mind the resource consumption > >>>> and at no-point should we cross this limit, come what may. If we hit > >>>> this limit, the create command > >>>> should fail asking the user to delete snaps using the "snapshot > >>>> delete" command. > >>>> > >>>> The two options Raghavendra mentioned are applicable for the > >>>> soft-limit only, in which cases on > >>>> hitting the soft-limit > >>>> > >>>> 1. Trigger auto-delete > >>>> > >>>> or > >>>> > >>>> 2. Log a warning-message, for the user saying the number of snaps is > >>>> exceeding the snap-limit and > >>>> display the number of available snaps > >>>> > >>>> Now which of these should happen also depends on the user, because the > >>>> auto-delete option > >>>> is configurable. > >>>> > >>>> So if the auto-delete option is set as true, auto-delete should be > >>>> triggered and the above message > >>>> should also be logged. > >>>> > >>>> But if the option is set as false, only the message should be logged. > >>>> > >>>> This is the behaviour as designed. Adding Rahul, and Seema in the > >>>> mail, to reflect upon the > >>>> behaviour as well. > >>>> > >>>> Regards, > >>>> Avra > >>>> > >>> > >>> This sounds correct. However we need to make sure that the usage or > >>> documentation around this should be good enough , so that users > >>> understand the each of the limits correctly. > >>> > >>> > >> It might be better to avoid the usage of the term "soft-limit". > >> soft-limit as used in quota and other places generally has an alerting > >> connotation. Something like "auto-deletion-limit" might be better. > >> > >> > > I still see references to "soft-limit" and auto deletion seems to get > > triggered upon reaching soft-limit. > > > > Why is the ability to auto delete not configurable? It does seem pretty > > nasty to go about deleting snapshots without obtaining explicit consent > > from the user. > > > > I agree with Vijay here. It's not good to delete a snap (even though it is > oldest) without the explicit consent from user. > > FYI It took me more than 2 weeks to figure out that my snaps were getting > autodeleted after reaching "soft-limit". For all I know I had not done > anything and my snap restore were failing. > > I propose to remove the terms "soft" and "hard" limit. I believe there > should be a limit (just "limit") after which all snapshot creates should > fail with proper error messages. And there can be a water-mark after which > user should get warning messages. So below is my proposal. > > *auto-delete + snap-limit: *If the snap-limit is set to *n*, next snap > create (n+1th) will succeed *only if* *if auto-delete is set to on/true/1* > and oldest snap will get deleted automatically. If autodelete is set to > off/false/0 , (n+1)th snap create will fail with proper error message from > gluster CLI command. But again by default autodelete should be off. > > *snap-water-mark*: This should come in picture only if autodelete is turned > off. It should not have any meaning if auto-delete is turned ON. Basically > it's usage is to give the user warning that limit almost being reached and > it is time for admin to decide which snaps should be deleted (or which > should be kept) > > *my two cents* > > -MS > > > > > > Cheers, > > > > Vijay > > > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] autodelete in snapshots
On 3 June 2014 01:02, M S Vishwanath Bhat wrote: > > > > On 2 June 2014 20:22, Vijay Bellur wrote: > >> On 04/23/2014 05:50 AM, Vijay Bellur wrote: >> >>> On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: >>> On 04/16/2014 11:39 AM, Avra Sengupta wrote: > The whole purpose of introducing the soft-limit is, that at any point > of time the number of > snaps should not exceed the hard limit. If we trigger auto-delete on > hitting hard-limit, then > the purpose itself is lost, because at that point we would be taking a > snap, making the limit > hard-limit + 1, and then triggering auto-delete, which violates the > sanctity of the hard-limit. > Also what happens when we are at hard-limit + 1, and another snap is > issued, while auto-delete > is yet to process the first delete. At that point we end up at > hard-limit + 1. Also what happens > if for a particular snap the auto-delete fails. > > We should see the hard-limit, as something set by the admin keeping in > mind the resource consumption > and at no-point should we cross this limit, come what may. If we hit > this limit, the create command > should fail asking the user to delete snaps using the "snapshot > delete" command. > > The two options Raghavendra mentioned are applicable for the > soft-limit only, in which cases on > hitting the soft-limit > > 1. Trigger auto-delete > > or > > 2. Log a warning-message, for the user saying the number of snaps is > exceeding the snap-limit and > display the number of available snaps > > Now which of these should happen also depends on the user, because the > auto-delete option > is configurable. > > So if the auto-delete option is set as true, auto-delete should be > triggered and the above message > should also be logged. > > But if the option is set as false, only the message should be logged. > > This is the behaviour as designed. Adding Rahul, and Seema in the > mail, to reflect upon the > behaviour as well. > > Regards, > Avra > This sounds correct. However we need to make sure that the usage or documentation around this should be good enough , so that users understand the each of the limits correctly. >>> It might be better to avoid the usage of the term "soft-limit". >>> soft-limit as used in quota and other places generally has an alerting >>> connotation. Something like "auto-deletion-limit" might be better. >>> >>> >> I still see references to "soft-limit" and auto deletion seems to get >> triggered upon reaching soft-limit. >> >> Why is the ability to auto delete not configurable? It does seem pretty >> nasty to go about deleting snapshots without obtaining explicit consent >> from the user. >> > > I agree with Vijay here. It's not good to delete a snap (even though it is > oldest) without the explicit consent from user. > > FYI It took me more than 2 weeks to figure out that my snaps were getting > autodeleted after reaching "soft-limit". For all I know I had not done > anything and my snap restore were failing. > > I propose to remove the terms "soft" and "hard" limit. I believe there > should be a limit (just "limit") after which all snapshot creates should > fail with proper error messages. And there can be a water-mark after which > user should get warning messages. So below is my proposal. > > *auto-delete + snap-limit: *If the snap-limit is set to *n*, next snap > create (n+1th) will succeed *only if* *if auto-delete is set to on/true/1* > and oldest snap will get deleted automatically. If autodelete is set to > off/false/0 , (n+1)th snap create will fail with proper error message from > gluster CLI command. But again by default autodelete should be off. > > *snap-water-mark*: This should come in picture only if autodelete is > turned off. It should not have any meaning if auto-delete is turned ON. > Basically it's usage is to give the user warning that limit almost being > reached and it is time for admin to decide which snaps should be deleted > (or which should be kept) > > *my two cents* > Adding gluster-users as well. -MS > > -MS > > >> >> Cheers, >> >> Vijay >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://supercolony.gluster.org/mailman/listinfo/gluster-devel >> > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] autodelete in snapshots
On 2 June 2014 20:22, Vijay Bellur wrote: > On 04/23/2014 05:50 AM, Vijay Bellur wrote: > >> On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: >> >>> On 04/16/2014 11:39 AM, Avra Sengupta wrote: >>> The whole purpose of introducing the soft-limit is, that at any point of time the number of snaps should not exceed the hard limit. If we trigger auto-delete on hitting hard-limit, then the purpose itself is lost, because at that point we would be taking a snap, making the limit hard-limit + 1, and then triggering auto-delete, which violates the sanctity of the hard-limit. Also what happens when we are at hard-limit + 1, and another snap is issued, while auto-delete is yet to process the first delete. At that point we end up at hard-limit + 1. Also what happens if for a particular snap the auto-delete fails. We should see the hard-limit, as something set by the admin keeping in mind the resource consumption and at no-point should we cross this limit, come what may. If we hit this limit, the create command should fail asking the user to delete snaps using the "snapshot delete" command. The two options Raghavendra mentioned are applicable for the soft-limit only, in which cases on hitting the soft-limit 1. Trigger auto-delete or 2. Log a warning-message, for the user saying the number of snaps is exceeding the snap-limit and display the number of available snaps Now which of these should happen also depends on the user, because the auto-delete option is configurable. So if the auto-delete option is set as true, auto-delete should be triggered and the above message should also be logged. But if the option is set as false, only the message should be logged. This is the behaviour as designed. Adding Rahul, and Seema in the mail, to reflect upon the behaviour as well. Regards, Avra >>> >>> This sounds correct. However we need to make sure that the usage or >>> documentation around this should be good enough , so that users >>> understand the each of the limits correctly. >>> >>> >> It might be better to avoid the usage of the term "soft-limit". >> soft-limit as used in quota and other places generally has an alerting >> connotation. Something like "auto-deletion-limit" might be better. >> >> > I still see references to "soft-limit" and auto deletion seems to get > triggered upon reaching soft-limit. > > Why is the ability to auto delete not configurable? It does seem pretty > nasty to go about deleting snapshots without obtaining explicit consent > from the user. > I agree with Vijay here. It's not good to delete a snap (even though it is oldest) without the explicit consent from user. FYI It took me more than 2 weeks to figure out that my snaps were getting autodeleted after reaching "soft-limit". For all I know I had not done anything and my snap restore were failing. I propose to remove the terms "soft" and "hard" limit. I believe there should be a limit (just "limit") after which all snapshot creates should fail with proper error messages. And there can be a water-mark after which user should get warning messages. So below is my proposal. *auto-delete + snap-limit: *If the snap-limit is set to *n*, next snap create (n+1th) will succeed *only if* *if auto-delete is set to on/true/1* and oldest snap will get deleted automatically. If autodelete is set to off/false/0 , (n+1)th snap create will fail with proper error message from gluster CLI command. But again by default autodelete should be off. *snap-water-mark*: This should come in picture only if autodelete is turned off. It should not have any meaning if auto-delete is turned ON. Basically it's usage is to give the user warning that limit almost being reached and it is time for admin to decide which snaps should be deleted (or which should be kept) *my two cents* -MS > > Cheers, > > Vijay > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] autodelete in snapshots
On 04/23/2014 05:50 AM, Vijay Bellur wrote: On 04/20/2014 11:42 PM, Lalatendu Mohanty wrote: On 04/16/2014 11:39 AM, Avra Sengupta wrote: The whole purpose of introducing the soft-limit is, that at any point of time the number of snaps should not exceed the hard limit. If we trigger auto-delete on hitting hard-limit, then the purpose itself is lost, because at that point we would be taking a snap, making the limit hard-limit + 1, and then triggering auto-delete, which violates the sanctity of the hard-limit. Also what happens when we are at hard-limit + 1, and another snap is issued, while auto-delete is yet to process the first delete. At that point we end up at hard-limit + 1. Also what happens if for a particular snap the auto-delete fails. We should see the hard-limit, as something set by the admin keeping in mind the resource consumption and at no-point should we cross this limit, come what may. If we hit this limit, the create command should fail asking the user to delete snaps using the "snapshot delete" command. The two options Raghavendra mentioned are applicable for the soft-limit only, in which cases on hitting the soft-limit 1. Trigger auto-delete or 2. Log a warning-message, for the user saying the number of snaps is exceeding the snap-limit and display the number of available snaps Now which of these should happen also depends on the user, because the auto-delete option is configurable. So if the auto-delete option is set as true, auto-delete should be triggered and the above message should also be logged. But if the option is set as false, only the message should be logged. This is the behaviour as designed. Adding Rahul, and Seema in the mail, to reflect upon the behaviour as well. Regards, Avra This sounds correct. However we need to make sure that the usage or documentation around this should be good enough , so that users understand the each of the limits correctly. It might be better to avoid the usage of the term "soft-limit". soft-limit as used in quota and other places generally has an alerting connotation. Something like "auto-deletion-limit" might be better. I still see references to "soft-limit" and auto deletion seems to get triggered upon reaching soft-limit. Why is the ability to auto delete not configurable? It does seem pretty nasty to go about deleting snapshots without obtaining explicit consent from the user. Cheers, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
