Since this is an open source community project, not a company product,
feature requests like these are welcome, but would be more welcome with
either code or at least a well described method. Broad asks like these
are of little value, imho.
On 04/29/2017 07:12 AM, Gandalf Corvotempesta wrote:> Anyway, the proposed workaround:
>
https://joejulian.name/blog/how-to-expand-glusterfs-replicated-clusters-by-one-server/
> won't work with just a single volume made up of 2 replicated bricks.
> If I have a replica 2 volume with server1:brick1 and server2:brick1,
> how can I add server3:brick1 ?
> I don't have any bricks to "replace"
>
> This is something i would like to see implemented in gluster.
>
> 2017-04-29 16:08 GMT+02:00 Gandalf Corvotempesta
> <gandalf.corvotempesta at gmail.com>:
>> 2017-04-24 10:21 GMT+02:00 Pranith Kumar Karampuri <pkarampu at
redhat.com>:
>>> Are you suggesting this process to be easier through commands,
rather than
>>> for administrators to figure out how to place the data?
>>>
>>> [1]
http://lists.gluster.org/pipermail/gluster-users/2016-July/027431.html
>> Admin should always have the ability to choose where to place data,
>> but something
>> easier should be added, like in any other SDS.
>>
>> Something like:
>>
>> gluster volume add-brick gv0 new_brick
>>
>> if gv0 is a replicated volume, the add-brick should automatically add
>> the new brick and rebalance data automatically, still keeping the
>> required redundancy level
>>
>> In case admin would like to set a custom placement for data, it should
>> specify a "force" argument or something similiar.
>>
>> tl;dr: as default, gluster should preserve data redundancy allowing
>> users to add single bricks without having to think how to place data.
>> This will make gluster way easier to manage and much less error prone,
>> thus increasing the resiliency of the whole gluster.
>> after all , if you have a replicated volume, is obvious that you want
>> your data to be replicated and gluster should manage this on it's
own.
>>
>> Is this something are you planning or considering for further
implementation?
>> I know that lack of metadata server (this is a HUGE advantage for
>> gluster) means less flexibility, but as there is a manual workaround
>> for adding
>> single bricks, gluster should be able to handle this automatically.
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users