Gluster users - May 2017 - Add single server

On 05/01/2017 11:36 AM, Pranith Kumar Karampuri wrote:
>
>
> On Tue, May 2, 2017 at 12:04 AM, Gandalf Corvotempesta 
> <gandalf.corvotempesta at gmail.com 
> <mailto:gandalf.corvotempesta at gmail.com>> wrote:
>
>     2017-05-01 20:30 GMT+02:00 Shyam <srangana at redhat.com
>     <mailto:srangana at redhat.com>>:
>     > Yes, as a matter of fact, you can do this today using the CLI
>     and creating
>     > nx2 instead of 1x2. 'n' is best decided by you, depending
on the
>     growth
>     > potential of your cluster, as at some point 'n' wont be
enough
>     if you grow
>     > by some nodes.
>     >
>     > But, when a brick is replaced we will fail to address "(a)
>     ability to retain
>     > replication/availability levels" as we support only
homogeneous
>     replication
>     > counts across all DHT subvols. (I could be corrected on this
>     when using
>     > replace-brick though)
>
>
>     Yes, but this is error prone.
>
>
> Why?
>
Because it's done by humans.
>
>     I'm still thinking that saving (I don't know where, I don't
know how)
>     a mapping between
>     files and bricks would solve many issues and add much more
>     flexibility.
>
>
>
>
> -- 
> Pranith
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170501/451ad626/attachment.html>

On 05/01/2017 02:42 PM, Joe Julian wrote:
>
>
> On 05/01/2017 11:36 AM, Pranith Kumar Karampuri wrote:
>>
>>
>> On Tue, May 2, 2017 at 12:04 AM, Gandalf Corvotempesta
>> <gandalf.corvotempesta at gmail.com
>> <mailto:gandalf.corvotempesta at gmail.com>> wrote:
>>
>>     2017-05-01 20:30 GMT+02:00 Shyam <srangana at redhat.com
>>     <mailto:srangana at redhat.com>>:
>>     > Yes, as a matter of fact, you can do this today using the CLI
>>     and creating
>>     > nx2 instead of 1x2. 'n' is best decided by you,
depending on the
>>     growth
>>     > potential of your cluster, as at some point 'n' wont
be enough
>>     if you grow
>>     > by some nodes.
>>     >
>>     > But, when a brick is replaced we will fail to address
"(a)
>>     ability to retain
>>     > replication/availability levels" as we support only
homogeneous
>>     replication
>>     > counts across all DHT subvols. (I could be corrected on this
>>     when using
>>     > replace-brick though)
>>
>>
>>     Yes, but this is error prone.
>>
>>
>> Why?
>>
>
> Because it's done by humans.
Fair point. If Gandalf concurs, we will add this to our "+1 scaling" 
feature effort (not yet on github as an issue).
>
>>
>>     I'm still thinking that saving (I don't know where, I
don't know how)
>>     a mapping between
>>     files and bricks would solve many issues and add much more
>>     flexibility.
>>
>>
>>
>>
>> --
>> Pranith
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>

2017-05-01 20:42 GMT+02:00 Joe Julian <joe at
julianfamily.org>:
> Because it's done by humans.
Exactly. I forgot to mention this.