Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-14 Thread Gandalf Corvotempesta
Il 14 nov 2016 7:28 PM, "Joe Julian"  ha scritto:
>
> IMHO, if a command will result in data loss, fall it. Period.
>
> It should never be ok for a filesystem to lose data. If someone wanted to
do that with ext or xfs they would have to format.
>

Exactly. I've wrote something similiar in some mail.
Gluster should preserve data consistency at any cost.
If you are trying to do something bad, this should be blocked or, AT
MINIMUM,  a confirm must be asked

Like doing fsck on a mounted FS
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-14 Thread Joe Julian
IMHO, if a command will result in data loss, fall it. Period.

It should never be ok for a filesystem to lose data. If someone wanted to do 
that with ext or xfs they would have to format. 

On November 14, 2016 8:15:16 AM PST, Ravishankar N  
wrote:
>On 11/14/2016 05:57 PM, Atin Mukherjee wrote:
>> This would be a straight forward thing to implement at glusterd, 
>> anyone up for it? If not, we will take this into consideration for 
>> GlusterD 2.0.
>>
>> On Mon, Nov 14, 2016 at 10:28 AM, Mohammed Rafi K C 
>> > wrote:
>>
>> I think it is worth to implement a lock option.
>>
>> +1
>>
>>
>> Rafi KC
>>
>>
>> On 11/14/2016 06:12 AM, David Gossage wrote:
>>> On Sun, Nov 13, 2016 at 6:35 PM, Lindsay Mathieson
>>> >> > wrote:
>>>
>>> As discussed recently, it is way to easy to make destructive
>>> changes
>>> to a volume,e.g change shard size. This can corrupt the data
>>> with no
>>> warnings and its all to easy to make a typo or access the
>>> wrong volume
>>> when doing 3am maintenance ...
>>>
>>> So I'd like to suggest something like the following:
>>>
>>>   gluster volume lock 
>>>
>
>
>I don't think this is a good idea. It would make more sense to give out
>
>verbose warnings in the individual commands themselves. A volume lock 
>doesn't prevent users from unlocking and still inadvertently running 
>those commands without knowing the implications. The remove brick set
>of 
>commands provides verbose messages nicely:
>
>$gluster v remove-brick testvol 127.0.0.2:/home/ravi/bricks/brick{4..6}
>
>commit
>Removing brick(s) can result in data loss. Do you want to Continue?
>(y/n) y
>volume remove-brick commit: success
>Check the removed bricks to ensure all files are migrated.
>If files with data are found on the brick path, copy them via a gluster
>
>mount point before re-purposing the removed brick
>
>My 2 cents,
>Ravi
>
>
>>>
>>> Setting this would fail all:
>>> - setting changes
>>> - add bricks
>>> - remove bricks
>>> - delete volume
>>>
>>>   gluster volume unlock 
>>>
>>> would allow all changes to be made.
>>>
>>> Just a thought, open to alternate suggestions.
>>>
>>> Thanks
>>>
>>> +
>>> sounds handy
>>>
>>> --
>>> Lindsay
>>> ___
>>> Gluster-users mailing list
>>> gluster-us...@gluster.org 
>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> Gluster-users mailing list
>>> gluster-us...@gluster.org 
>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>> 
>> ___ Gluster-devel
>> mailing list Gluster-devel@gluster.org
>> 
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>  
>>
>> -- 
>> ~ Atin (atinm)
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
>
>___
>Gluster-devel mailing list
>Gluster-devel@gluster.org
>http://www.gluster.org/mailman/listinfo/gluster-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-14 Thread Ravishankar N

On 11/14/2016 05:57 PM, Atin Mukherjee wrote:
This would be a straight forward thing to implement at glusterd, 
anyone up for it? If not, we will take this into consideration for 
GlusterD 2.0.


On Mon, Nov 14, 2016 at 10:28 AM, Mohammed Rafi K C 
> wrote:


I think it is worth to implement a lock option.

+1


Rafi KC


On 11/14/2016 06:12 AM, David Gossage wrote:

On Sun, Nov 13, 2016 at 6:35 PM, Lindsay Mathieson
> wrote:

As discussed recently, it is way to easy to make destructive
changes
to a volume,e.g change shard size. This can corrupt the data
with no
warnings and its all to easy to make a typo or access the
wrong volume
when doing 3am maintenance ...

So I'd like to suggest something like the following:

  gluster volume lock 




I don't think this is a good idea. It would make more sense to give out 
verbose warnings in the individual commands themselves. A volume lock 
doesn't prevent users from unlocking and still inadvertently running 
those commands without knowing the implications. The remove brick set of 
commands provides verbose messages nicely:


$gluster v remove-brick testvol 127.0.0.2:/home/ravi/bricks/brick{4..6} 
commit

Removing brick(s) can result in data loss. Do you want to Continue? (y/n) y
volume remove-brick commit: success
Check the removed bricks to ensure all files are migrated.
If files with data are found on the brick path, copy them via a gluster 
mount point before re-purposing the removed brick


My 2 cents,
Ravi




Setting this would fail all:
- setting changes
- add bricks
- remove bricks
- delete volume

  gluster volume unlock 

would allow all changes to be made.

Just a thought, open to alternate suggestions.

Thanks

+
sounds handy

--
Lindsay
___
Gluster-users mailing list
gluster-us...@gluster.org 
http://www.gluster.org/mailman/listinfo/gluster-users





___
Gluster-users mailing list
gluster-us...@gluster.org 
http://www.gluster.org/mailman/listinfo/gluster-users


___ Gluster-devel
mailing list Gluster-devel@gluster.org

http://www.gluster.org/mailman/listinfo/gluster-devel
 


--
~ Atin (atinm)

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-14 Thread Atin Mukherjee
This would be a straight forward thing to implement at glusterd, anyone up
for it? If not, we will take this into consideration for GlusterD 2.0.

On Mon, Nov 14, 2016 at 10:28 AM, Mohammed Rafi K C 
wrote:

> I think it is worth to implement a lock option.
>
> +1
>
>
> Rafi KC
>
> On 11/14/2016 06:12 AM, David Gossage wrote:
>
> On Sun, Nov 13, 2016 at 6:35 PM, Lindsay Mathieson <
> lindsay.mathie...@gmail.com> wrote:
>
>> As discussed recently, it is way to easy to make destructive changes
>> to a volume,e.g change shard size. This can corrupt the data with no
>> warnings and its all to easy to make a typo or access the wrong volume
>> when doing 3am maintenance ...
>>
>> So I'd like to suggest something like the following:
>>
>>   gluster volume lock 
>>
>> Setting this would fail all:
>> - setting changes
>> - add bricks
>> - remove bricks
>> - delete volume
>>
>>   gluster volume unlock 
>>
>> would allow all changes to be made.
>>
>> Just a thought, open to alternate suggestions.
>>
>> Thanks
>>
>> +
> sounds handy
>
>> --
>> Lindsay
>> ___
>> Gluster-users mailing list
>> gluster-us...@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
>
>
> ___
> Gluster-users mailing 
> listGluster-users@gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-users
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 

~ Atin (atinm)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-13 Thread Mohammed Rafi K C
I think it is worth to implement a lock option.

+1


Rafi KC


On 11/14/2016 06:12 AM, David Gossage wrote:
> On Sun, Nov 13, 2016 at 6:35 PM, Lindsay Mathieson
> > wrote:
>
> As discussed recently, it is way to easy to make destructive changes
> to a volume,e.g change shard size. This can corrupt the data with no
> warnings and its all to easy to make a typo or access the wrong volume
> when doing 3am maintenance ...
>
> So I'd like to suggest something like the following:
>
>   gluster volume lock 
>
> Setting this would fail all:
> - setting changes
> - add bricks
> - remove bricks
> - delete volume
>
>   gluster volume unlock 
>
> would allow all changes to be made.
>
> Just a thought, open to alternate suggestions.
>
> Thanks
>
> +
> sounds handy 
>
> --
> Lindsay
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org 
> http://www.gluster.org/mailman/listinfo/gluster-users
> 
>
>
>
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feature Request: Lock Volume Settings

2016-11-13 Thread David Gossage
On Sun, Nov 13, 2016 at 6:35 PM, Lindsay Mathieson <
lindsay.mathie...@gmail.com> wrote:

> As discussed recently, it is way to easy to make destructive changes
> to a volume,e.g change shard size. This can corrupt the data with no
> warnings and its all to easy to make a typo or access the wrong volume
> when doing 3am maintenance ...
>
> So I'd like to suggest something like the following:
>
>   gluster volume lock 
>
> Setting this would fail all:
> - setting changes
> - add bricks
> - remove bricks
> - delete volume
>
>   gluster volume unlock 
>
> would allow all changes to be made.
>
> Just a thought, open to alternate suggestions.
>
> Thanks
>
> +
sounds handy

> --
> Lindsay
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel