I'm pretty sure that I'll be able to sleep well even after your block.
Il 29 apr 2017 11:28 PM, "Joe Julian" <joe@xxxxxxxxxxxxxxxx> ha scritto:
No, you proposed a wish. A feature needs described behavior, certainly a lot more than "it should just know what I want it to do".
I'm done. You can continue to feel entitled here on the mailing list. I'll just set my filters to bitbucket anything from you.
On 04/29/2017 01:00 PM, Gandalf Corvotempesta wrote:
I repeat: I've just proposed a featureI'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" <joe@xxxxxxxxxxxxxxxx> 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.corvotempesta@gmail.com > wrote:Mine was a suggestionFell 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" <joe@xxxxxxxxxxxxxxxx> 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.corvotempesta@gmail.com >:
2017-04-24 10:21 GMT+02:00 Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx>:______________________________
Are you suggesting this process to be easier through commands, rather thanAdmin should always have the ability to choose where to place data,
for administrators to figure out how to place the data?
[1] http://lists.gluster.org/pipermail/gluster-users/2016-July/0 27431.html
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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
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@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
