I repeat: I've just proposed a feature I'm not a C developer and I don't know gluster internals, so I can't provide details
I've just asked if simplifying the add brick process is something that developers are interested to add Il 29 apr 2017 9:34 PM, "Joe Julian" <j...@julianfamily.org> ha scritto: > What I said publicly in another email ... but not to call out my > perception of your behavior publicly if also like to say: > > Acting adversarial doesn't make anybody want to help, especially not me > and I'm the user community's biggest proponent. > > On April 29, 2017 11:08:45 AM PDT, Gandalf Corvotempesta < > gandalf.corvotempe...@gmail.com> wrote: >> >> Mine was a suggestion >> Fell free to ignore was gluster users has to say and still keep going >> though your way >> >> Usually, open source project tends to follow users suggestions >> >> Il 29 apr 2017 5:32 PM, "Joe Julian" <j...@julianfamily.org> ha scritto: >> >>> 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-replicat >>>> ed-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.corvotempe...@gmail.com>: >>>> >>>>> 2017-04-24 10:21 GMT+02:00 Pranith Kumar Karampuri < >>>>> pkara...@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/0 >>>>>> 27431.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@gluster.org >>>> http://lists.gluster.org/mailman/listinfo/gluster-users >>>> >>> >>> _______________________________________________ >>> Gluster-users mailing list >>> Gluster-users@gluster.org >>> http://lists.gluster.org/mailman/listinfo/gluster-users >>> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
_______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users