Changing Redis master-slave replication terms with something else
antirez opened this issue · comments
(Note: I'll update the description here as the discussion evolves)
Background
It was asked multiple times by activists in the area of inclusiveness for Redis to migrate to a different terminology than master-slave, specifically one that has no reference to slavery. Personally I do not consider the effort worthwhile, but this is my personal opinion. On the other hand different Twitter threads, especially an exchange with DHH, together with many accounts of people starting to suggest to never use Redis again, made me reflecting about a few things. Specifically I think that it could be a problem for engineers just willing to use Redis because they believe is the right too for the job, to apply it in certain workplaces, because the terminology used in Redis may be a problem. I don't want, as a result of my ideas, to create problems to the Redis community.
At the same time once I started to be more open to the possibility of renaming such terms, I started to receive private complains from multiple people that contribute to the project for years, that are annoyed by the fact we'll have to do work that will not change the system in any way, and that will be costly, create compatibility issues.
My idea is to find a middle ground between all those things, because there are multiple issues caused by the change of terminology:
- PRs will no longer apply.
- We have commands such as
INFOandROLEthat reply with protocol containing the slave term. - There are 1500 occurrences inside the source code of the term slave.
- People having private trees and merging things as needed will get a lot of problems.
So this change can potentially create a lot of issues. Moreover many folks on Twitter do not understand the Redis culture of backward compatibility. Redis 5 that is now release candidate is backward compatible with the first stable version of Redis released, to the point it's a drop in replacement. This culture traditionally made sure that upgrade operations are simple, there is no useless work to do in the client side, and so forth. This is something big to consider.
Possible soltuion
Yet I want to give a signal, because in a Twitter pool I started too many people asked for the terminology to be changed. While I handle the Redis community, I do not want to be its king, I need to serve people here. A signal however does not need to create a number of problems across the community, so this is what I propose to do.
Short term changes
To start we do the following:
- Change the documentation to refer to master-replica. If we take master, which should not offend anybody in 2018 (next year we'll see...), at least there are less things to change. Replicas is very used and is also used inside Redis Cluster already.
- Alias SLAVEOF to REPLICAOF. You can still use SLAVEOF but now there is an option.
- Refer to REPLICAOF inside the documentation.
- Change the configuration directive as well from
slaveoftoreplicaof. - Leave all the internals as they are mentioning still slave at source level as a first step. Changing all those things now would be a big issue because we are at release candidate state, and there are too many pending PRs.
- Continue to reply with
slaveto INFO and ROLE, because this is a major breakage, for now.
Long term changes
- At some point in the future, write an alternative to INFO, since anyway INFO is not the future of Redis data gathering... It's too limited, provides too many info at once, clients need to have to parse it. We'll design a new command, and in the new command we'll not refer to slaves, but to replicas.
- When we are going to break a lot of things anyway, like for example with the inclusion of RESPv3, also change the
ROLEcommand to output replica instead of slave. If clients detect it's a RESPv3 server, they now that ROLE will reply differently, that is, instead of "slave" it will reply with "replica". - The first thing that we'll have to replace a lot of things internally, because of some technical reason, so that many PRs will not apply anyway, switch the variable and function names as well. However this is not acceptable to do as a change out of context, because it will cause really a lot of problems. We have to put this inside a much larger change somewhere.
We'll provide no ETA for the second step, and I hope the community will understand our technical issues here. However I hope that people will appreciate that at least somebody is listening here. Certain people demanding this change are vocal and hostile, but I saw a huge amount of people on Twitter just asking peacefully to see some improvement. One thing is for sure: the master-slave terminology is not going to be used in the future, so let's make this change together, and move forward to our actual work, that is, to make Redis better and available.
Please provide your POV if you are among the contributors of Redis
I know this may seem gross, but I would like most comments here to be provided by people that did something in Redis-land in the latest few years. People sending PRs, opening issues, writing a client library, using Redis at scale and provided hints regularly, and so forth, don't just comment if you are a casual Github user jumping here to say "change it!" or "don't change it". This will just create noise. Thanks.
Off topic and offensive comments will be removed
Hi Salvatore. Thanks for this post.
This does make sense. One technical note - I'm not sure REPLICATE is a good alternative to SLAVEOF. It implies (at least to me) to mean what the master is doing, not the slave replica. May I suggest FOLLOW <master>? it's not a perfect analogy but to me conveys less semantic ambiguity, which REPLICATE certainly does.
@dvirsky thanks for commenting. Yep I understand it may create issues, could be really cool to have the config directive that is similar to the name we give to replicas.
I think REPLICAOF would to me be an easier migration and feels more right than REPLICATE - totally subjective though and curious what others think.
I wonder if "master" should become "primary" for the sake of a clean break on both terms. I think it'd be much easier to explain to someone. For what it's worth, we use master and primary interchangeably when describing our topology all the time.
In recorded media Master also means the single source of truth, and there is no term for slave, and I doubt anyone has any problem with it. So I think keeping Master should be fine.
+1 for REPLICAOF
Indeed Marc, I think that ROLE could just return "master" and "replica" as well, exactly like we'll call them in other parts. However about the word master I want to be sure it is considered an acceptable replacement... If it's ok, I would love to at least take "master", because I find switching from "slave" to "replica" much simpler compared to calling the master something else, because when talking about Redis it was already in use to say replicas sometimes, but masters are always masters in the past documentation, in the way people talk when referring to Redis and so forth.
I'm updating the proposal with the suggestions so far.
Seems the best solution for what is mostly an unnecessary situation. Not breaking the entire ecosystem is good and +1 for ReplicaOf.
I'm with @NickCraver regarding replacing "master" with "primary". PostgreSQL has been using the same nomenclature for a long time now.
Solid plan, seems the least invasive path forward that mitigates breaking existing clients/systems. You can always do more later so makes sense to start with the least disruptive change to fix the problematic term first.
I'm fine with either "master" or "primary" but RESPv3 only gives you 1 chance at a breaking window so I'm more inclined to change it to "primary" there as well. It's minimal work for clients to handle both when adding support for RESPv3 and it's going to be prohibitively disruptive to change it later. (IMO "master" can be a more cosmetic change i.e. retain references in source but add aliases to "primary" and change defaults later in docs/config after RESPv3 becomes standard).
Over time the master/replica combo is going to sound unfamiliar and unique to Redis as I'm expecting everyone else to move to primary/replica to describe that relationship, so for the sake improved clarity/familiarity for future readers it might make sense that RESPv3 adopts both terms. But if you think the risk of breaking the ecosystem is too great then we should retain it, but whatever terms RESPv3 goes with I think should be retained permanently.
Personally I like primary/replica - it's a much more accurate metaphor than master/replica in my opinion. And using the same terminology as PostgreSQL is a big positive.
Folks I'm not interested in picking the most appropriate terminology here, but the one that is the minimum delta compared to what we are used, without being offensive to certain groups at the same time. If "master-replica" is not offensive, this is what I think we should use, because "primary" is really very far from historical terminology and to what we use in Redis-land. Master & replicas we already use, so I would stick with them if master is ok.
To clarify, I don't think that the semantical meaning is actually useful. Master-slave is totally bad at describing the two roles, but everybody understand what it is about, because in replication context you give to the words such meaning.
However @mythz has a point IMHO in that we should make totally sure that what we pick will not be sensed as wrong in a few years. But honestly this could happen anyway given the environment that is shaping out there.
I can't even imagine the amount of implications of the name change so I totally understand the pragmatic approach of keeping master and only renaming the slave. Anyway I went to one textbook I trust (Distributed Systems for System Architects. Authors: Veríssimo, Paulo, Rodrigues, Luís) and that was at hand and reminded myself of the different terminologies.
In replication there is a division between systems following active replication (where several replicas of the same state machine execute the same sequence of actions, often disseminated by atomic multicast) and passive replication (only one replica executes commands and others periodically catch up).
I guess the open source Redis case matches more the passive replication category, so lets look at the terminology there:
The special (elected or pre-configured) replica that executes the commands/actions first is called primary and the other replicas can be called secondary or backup. This leads to the terminology pairs primary/backup or primary/secondary. Now I also realize that this terminology is better that master/slave because both backup and secondary terms convey more the notion that those replicas can in the future replace the role of the primary.
To me the term replica does not equate immediately with something being a secondary to another entity. Also in geo-replicated settings, and others, we can have multiple active replicas and I believe the common term for this is still multi-master. The open source Redis, I believe, will fall in the single-master category.
Given all this, and given that there is a clear advantage in keeping master, maybe master/backup or master/secondary would be interesting options to consider in place of master/replica.
@mgravell removed my post to not offend any more people. Time to redirect your internet hero skills elsewhere. Too much care bear in this repo for my taste.
Relevant issue in Django: django/django#2692
They changed to leader/follower.
Please do not rush this and consider that Redis is used in many companies, by many consultants, trainers and users and that there is a consensus and a context to the use of master/slave just like there is to the use of various animal names.
Twitter users will just add a checkmark on their scoreboards and move on to a new target while your community will be left to deal with the aftermath.
@Yiftach I want to proceed with the first part, which should not be a huge amount of work at all, to give a first signal, because implementing the rest may likely take years... I don't want to do any ETA in the phase two. We'll slowly deprecate the "slave" term from the API and source code, but always when we have also a change at hand to justify it. RESPv3 for instance is the moment to fix ROLE, while for the INFO reply, we'll have to wait the introduction of an alternative to the INFO command. For removing it from the source code, it will be a very gradual process where from time to time a file or a part of a file is changed, so that we don't break a lot of PRs in the process. And so forth... So it's better to act right now with the part that gives a signal of change. This alone will change the documentation, that is the most exposed part of Redis, and will add the aliases, not breaking any compatibility, so it is definitely a doable stage-1. For all the rest, the community will have to understand that it is a big change that will require N years.
A few more places where aliases may be needed:
redis-clihas --slave mode, this can be easily changed to--replicamode.cluster replicasas an alias tocluster slaves.- You may want to consider including additional fields in the info command. Currently, we have
connected_slavesandslave0throughslaveN. Perhaps it makes sense to duplicate these fields asconnected_replicasandreplica0throughreplicaN? - Is there another term for
rolethat is acceptable? For example,functionornode_type? If so, perhaps we can add this new term in the info output, and also make a new alias for therolecommand? - The
cluster nodescommand outputs a list of flags. One of the flags is slave. Perhaps we can add anotherreplicaas another flag in addition to slave? This doesn't break the format - a parser is expected to parse multiple flags for a node anyways. And eventually, the slave flag can be removed.
With a little duplication and aliases, and assuming the changes are backported - clients can start using the new terms right away. Then a few releases later, the older terms can be dropped - perhaps when RESPv3 is introduced.
I like idea of striking middle ground (creating replica/replicaof alias) but keeping things backwards compatible. But the time spent on this means less time to work on other features (like Streams or module port of Disque).
I just removed a few sarcastic comments. Please don't post any more of comments of this kind and only comment if you got some idea to contribute to the issue.
I don’t believe that terminology out of context is offensive
especially if the context is the software
how much it will costs this change ? for the sake of ?
kindly suggest you to act like a benevolent dictator (here we are again), so please consider my words in the software context
i strongly think that "time" should be spent in a more usefull way
my 2eurocent,
p.s.
it seems that nowadays you cannot even use the name of some acient egypt gods to mark the intern codename relaeses like as has been done already for several years...
Just as a headsup it's on the front page of r/programming and might make way for unwanted comments. Post
Thanks much for Redis and all your efforts throughout the years.
this is funny... when we use master/slave,we didn't mean 'the' master/slave.
Can we engineers work with activists to create of a black word list by reviewing computer engineering terms currently used, before just made a change on 'slave' in Redis?
Such a list will be quite useful:
- Make multiple changes in one shot, reduce efforts
- Guide new software development and help fix existing software
- It's a quite educational thing for new programmers and engineers
- It could be used when doing a PC censorship check. For example, Github could use it to scan repositories and pull those don't follow the rule down from public accessing. Enterprise private VCS can use it preventing check-in which contains certain words
I (probably other people also) have some scripts that reference the 'master/slave' keywords. My suggestion is that anyone who is not happy with these terms can fork this project, change the terms whatever they like and leave the master/slave keywords of this project alone.
Since when did programming start to bow the whims of SJWs? Master/slave in the programming world has no ties to anything in human history related to human master/slave relationships. Simply because there is a negative connotation to the application of master/slave terms to humans does not mean the same thing applies to other domains. These are redis instances for crying out loud.
I definitely agree with @zhujinhe that if someone is so deeply offended by these words that they can't make the disconnect between modern programming and human history, they can start a fork of the project to suffice their needs. Lets focus on actual bug fixes and making the application work better instead of coddling the feelings of a small percentage of people.
@zhujinhe No API change will be performed in the first step. In the second step, API changes will be performed only when we'll introduce new APIs that were anyway planned (like a replacement for INFO), but this will take years. Your scripts will continue to work as expected.
White men pretending to be offended by a silly programming terminology after gentrifying the neighborhoods and destroying communities is something else. You are not going to solve anything by changing a couple of words in Redis. Start by working on your self; not fake, ego driven, internet karma.
Being offended is cheap, and Redis is a massive achievement. I urge you to not let the agendas of a few selfish individuals determine the course of this (or any) technology. Taking issues like these seriously sets a horrible precedent for the industry; it slows down innovation by removing focus from what actually matters.
What about
- KILL process
- USB MASTER/SLAVE
- Github MASTER branch
If you listen better to the motivations I stated in this issue, I think you would have avoided writing a number of comments. I agree that it is not the right direction, and I wrote a blog post about this, I just think that the society does not improve like that, even if the goal of inclusiveness per se is a good one. However I want to change it because outside of the activists circle it is clear that there are people that are starting to feel a discomfort in using a given terminology. It's starting to be a taboo. I think it's ok to avoid breaking things, but at least the signal of adding the aliases, and renaming the documentation, will cause Redis no harm at all and will make a certain part of the community happier to use Redis. People use technologies inside IT environments, and it is futile to put Redis and its users in an odd position just because we want to retain master-slave.
PC is the worst kind of censorship in the name of kindness. Please ignore those nonsense and keep on your great work!
just for fun
Those who believe he or she is a slave (or, the target of the expression) would consider a non-relevant term as having "special meaning", and trying to use the meaning everywhere.
This thing is just as ridiculous as when they think computer games are bloody and violent.
Why don't those who get offended just make a new distribution of Redis and call it "PC-Redis"?
It's open source.
I understand that the reason for this ticket is not to debate the issue but rather find a constructive approach to a solution. I understand this, but would like to chime in since I honestly don’t understand what’s going on.
My difficulty in understanding this issue stems from not being able to grasp what’s actually being requested here. The slave terminology used in this context does not refer to slave in the sense of a person being in slavery. Even Webster is clear on this where it has a separate definition for the context we’re using it in.
I assume the people that are advocating the change are not trying to protect a computer program. This means that what they are trying to protect is the feeling of people to which this term does apply, either currently or historically. I do not understand how removing this term from use in Redis facilitates this. Since it’s clear that the way this word is used in our context differs from how it applies to a human (again, see Webster), removing the term from use in Redis would not accomplish anything. Actually, I think it would make things worse.
So, I assume the goal is to remove this word from Redis (and other products) is to prevent people from being confronted with this “negative” term. Honestly, I feel this is not the right thing to do. We have negative words in our vocabulary to be able to conceptualize situations that are negative; to be able to reason about them. By removing this word from our vocabulary, we lose this option. Slavery is real; it does exist. According to an article by Unicef in 2016, an estimate of 45.8 million people are in slavery. People should understand this and not feel afraid to talk and think about this.
My opinion is that by removing this term from Redis, we’re actively working towards decreasing awareness of human slavery. The more a term like this is removed from every day use, the less people know about it. By trying to remove references to these kinds of words, we’re giving the impression it’s wrong to use them. We’d be actively encouraging suppression of these kinds of words. The only thing we achieve doing this is discouraging real discussion.
Instead of removing this wording from Redis, I propose an alternative solution. What I would do is add the following to the documentation, e.g. when this word is first introduced, reading something like this:
The term “slave” in the context of Redis refers to a different meaning of this word from the way it applies to a human being. Programs are not at risk to this kind of slavery, so don’t be concerned about them.
That being said, slavery does exist. We at Redis vehemently disapprove of slavery and would hope this issue one day disappears completely. However, today it does exist. According to some estimates, over 45 million people are in slavery today. This is something we should not ignore.
We have contemplated removing the word “slave” from the Redis product but have decided not to do so to encourage discussion on the real issue. By having this term still in the Redis product, we encourage people to explain to others what this word means in this context, and in other contexts. We hope that this way we don’t make people afraid to ask about this and to encourage an open discussion.
If you would like to contribute to the issue of slavery as it exists in the world today, please donate to Unicef or any of the other human rights organizations fighting to find a real solution.
To give everyone a recap of events, Salvatore receives a lot of criticism for having adopted MySQL's master/slave terminology that after one point of being called a "fascist" for his continued usage of the term prompted him to write a blog post defending its usage and suggesting the word itself didn't matter nearly as much as the more constructive ways where that energy/effort could be spent in making a difference in society. The post triggered more backlash from both a vocal minority but also from other prominent figures who love redis and want to see it being more accepting, eventually a conversation with dhh prompted him to reconsider changing the term which prompted a poll to gauge community feedback, the results indicate it's no longer a vocal minority but a majority of people (following @antirez on twitter at least) that would like to see Redis be more accepting and the term replaced.
Whether anyone feels its right or wrong, some PoC genuinely feel discomfort of because of the term and given there is under representation of PoC in technology, Redis's continued usage is seen as contributing to the problem. It also takes a lot of energy to continually resist calls for change and with all things considered Salvatore now wants to use more appropriate terminology for describing the roles. Please note that the stress of the events is causing Salvatore physical duress where it's no longer useful to debate the merits of the change which is going to cause even more stress. So lets please respect his wishes and constructively look at how we can make the change in the least disruptive way possible.
I originally thought given the RESPv3 breaking window that Redis should adopt both primary/replica terms for future proofing nomenclature, but thinking about it more I think master/replica is more appropriate than primary/replica. "Master" is used as both referring to the "Original" i.e. "Golden Master" and issuing commands like master/subordinate which I think fits the role better than "Primary" - given it's also a lot less disruptive to retain "master" I'm now in favor of using master/replica as in Salvatore's original thread.
As it was me suggesting primary above, I'd just like to chime in saying I completely agree on keeping master. After thinking about it longer, master/replica is a much better terminology for the reasons @mythz lists as well as the fact we'd have n "primaries" in the case of cluster which isn't good. Elasticsearch also uses master nodes, as an example. master/replica accurately conveys role in all the situations redis runs in.
I think the current plan is sound, and as library authors we're happy to help. I imagine the path we'll take is aliasing the client-side API as well and handling the client->server side aliasing based on version underneath. Let us know how to help.
How about master and servant?
I'm removing all the off-topic content here. Again folks, this ticket is not to explain anything but to get contributions. For instance, above, we get to the final conclusion to use master-replica. This is a useful process. Don't debate anymore about this being useless, I'll state it the final way how it works and why we change this, and remove anything else:
- Yes I believe that this is useless. I also believe that it is tragical that this social rights movement is labeling slavery to be associated with black skin, because labels make actual inclusion hard, and slavery had multiple instances with different populations.
- However at this point the damage is done because please accept that this "sensibility" crossed the line of a few activists, there are a number of Redis users that asked for this, including popular devs like DHH. When the environment is like that, the other POV of this being irrelevant is already lost, the only thing to do is to adapt.
- We are not going to break APIs. Only when old APIs are deprecated naturally we switch to the new terminology.
I also deleted tens of comments with a lot of different proposals than master-replica in order to take this issue more readable. The choice is master-replica, it has all the sort of benefits, including the huge one that this was already Redis terminology.
And... I started the work in a new branch. I'll publish the new commits daily for you to review. So far I'm converting:
- redis-cli usages of the word slave, adding aliases for backward compatibility.
- Logs emitted by the Redis server.
- Commands and configuration directives are moved to "replica", again, maintaining aliases.
So I'm focusing on the Redis code base. The documentation change will be done later after the first effort in the source tree is complete.
Yes you may delete my reply but as a source-code level user of Redis I have to say:
- Tons of business depends on this project, we have a lot of things to do, say SYNC/PSYNC, with improving redis core. If you must do this, please take your time and we are all looking forward to version 5,6,7...
- According to Oxford dictionary:
master
NOUN
1.historical. A man who has people working for him, especially servants or slaves.
see salves right? If they want, they will make you change the master-replica to tom-jerry someday.
Best regards.
The biggest issue for me in all of this is not just changing wording (which I already find senseless, but that's not the point), but the fact that somewhat universal terminology used across many engineering and programming fields is being changed for a thousand different versions for every case, which makes it harder to share knowledge, actually.
I really appreciate that you are going to keep Redis backwards compatible — breaking backwards compatibility will lead to real economical consequences as millions of hours will have to be invested worldwide to fix the legacy client code to use new wording.
I have two more point for keeping things as they are now:
- I live in Russia and we had 70 years of oppression against free speech during communist state before the fall of USSR. Me and many engineers coming from my country will be really offended by this kind of censorship.
- BIND DNS server and RFCs for DNS use the same master-slave terminology and I believe ISC can be held much more responsible for correct terminology in front of world community than a single human of you. But I have not heard about any discussions for changing wordings in that regard. I really think that ISC's approach (which speaks for the whole internet) justifies the use of the current wording.
I'm sorry but it's not my fault if at this point this way of thinking is so widespread. If it was just for me, I would say literally fuck off, but again, here I need to find compromises, and believe it or not, at this point in the Redis community there is a sizable amount of people that want such a change. So the compromise was to make it non breaking, but to give a signal. I would like the world to be different, but this is the IT where we live now. Consider that we are not conceptually accepting the idea itself, but we are just trying to understand that a non trivial part of the community has a given inclination, here we are not censoring anybody, but just accepting a status quo. IMHO this problem is to be fixed at the root... why so many people outside the activists circles asked for such a change?. But look at the world now, it's full of anti scientific shit everywhere, populistic governments, and simple solutions. I can only assure you that this change will take very little time (like one week), and we'll move forward without any breaking API change.
Work ongoing here: https://github.com/antirez/redis/commits/master-replica
If you want to help please review the changes instead of making all this even more difficult.
I would point out that in Kubernetes that "replicas" refers to the number of total instances. So "replicas" would be the total number of master nodes plus the total number of slave nodes. If Redis uses "replica" to refer solely to "slaves", then that will can easily cause confusion when trying to understand the total count. When describing a Redis Cluster in Kubernetes, I might say I have 9 replicas (i.e., 3 masters and 6 slaves), but when referring to the Redis configuration itself, I have 6 replicas.
In other databases (e.g., CouchDB), "replicas" references to the total number of copies of an entry (document) - not the state/role of a CouchDB instance. More generally, "replicas" refers to the number of copies of something. In a 1 Master + 1 Slave shard, there are 2 copies (or replicas) of the database.
Since we are talking about roles, given that Redis Cluster is a high availability solution, what about using Active/Standby? Or perhaps Master/Standby?
Conversation locked since unreasonable persons of course exist in the other side of the spectrum... No wonder btw, I'm an atheist but I truly have little respect for certain atheist associations that turn into a bunch of extremists, so why that would be different? I'll keep you posted commenting here.
Question (and reopening the comments here, hoping that the criticisms will settle): I think I finished the work in the Redis tree, branch master-replica. Can you spot more? AFAIK I changed everything that was possible to change without breaking backward compatibility:
- Log messages
- Command names now all have aliases not mentioning the term slave.
- Configuration directives have aliases not mentioning slaves, and those are the only one documented in the example redis.conf file.
- Configuration rewrites via
CONFIG REWRITEwill translate the old directives to the new ones. CONFIG SET/GETalso have access to the new names.
AFAIK that's the max we can achieve. Now I'm going to address the documentation... If you have any suggestion about the commits, please comment here. I hope I'll not need to close comments again.
@fdingiit can't see anything related to logging or configuration directives so far. Note that there is no aim at replacing the internal variables and function names so far, since there are plenty PRs that would no longer apply and we would break private forks that rely on the ability to cherry-pick changes as well.
Yes I've read you message just now, about logging and command things, I will use this branch to do some testing.
We have a lot of scripts and using some third-party clients, hope it works.
No important, but you may need to change slave in testcases some day.
For example in replication-psync.tcl
Thanks @fdingiit, please let me know if everything still works!
73 2448:S 11 Sep 2018 19:02:13.518 - 2 clients connected (0 replicas), 1945648 bytes in use
74 2448:S 11 Sep 2018 19:02:18.527 - 2 clients connected (0 replicas), 1945648 bytes in use
75 2448:S 11 Sep 2018 19:02:23.535 - 2 clients connected (0 replicas), 1945648 bytes in use
76 2448:S 11 Sep 2018 19:02:28.546 - 2 clients connected (0 replicas), 1945648 bytes in use
77 2448:S 11 Sep 2018 19:02:33.555 - 2 clients connected (0 replicas), 1945648 bytes in use
hi, this is from log, better to change the S(lave) to R?
like #5340 maybe?
@fdingiit this would break parsing of Redis logs... and the "S" alone should not be very offensive hopefully.
Important: I just merged the master-replica branch into unstable. Work will continue there.
@antirez What do you think about #5335 (comment)
Specifically, duplicating information in info and cluster nodes output?
Thank you for the effort to make an open discussion around the problem even under pressure of whining offended people. And thank you, that you didn’t just lock and close a change request ignoring a number of people who disagree, voting down and comment that it doesn’t make any sense. You were able to do a much better job around the issue than “liberal” facebook for example, who just implements changes and lock down discussions been downvoted. Respect you for having balls to talk and question the position of very loud concerned minorities.
I very sad seen this flow of wasting of time, inaccurate or dangerous changes across many open source projects, especially in the last week, it’s a well-done attack. From my point of view, you made some mistakes in organizing pools and discussions that exposed you to the attack even more. For example, by using twitter you targeted loud minor groups that force their opinion and people who mostly don’t actually use Redis at all, not the people who really care - it’s too cheap nowadays to run loud around with all this standard privileged, patriarchy, etc topic and request for changes and you got opinions of these people. People who actually were installing Redis that moment don’t have twitter at all in a lot of cases. I think in downvotes to this change request you see something closer to a real distribution.
As a developer in a company that uses a lot of Redis installations - I’m pretty scared about the times you will start to remove old APIs to get rid of this words completely. We have a large codebase of disaster recovery scripts for different situations that nobody actively uses, but they are documented and prepared for use. It will be an expensive moment in our company when we can’t use one of this script quickly because Redis dropped support of some API. I understand that this moment is postponed in the future, but if you are going to remove such old APIs one day - it will happen. If it’s possible, please do really loud announcements when you first start to break backward compatibility and remove the old APIs, we will likely just stay on the last compatible version “forever” for my current company. Redis is stable enough for us to afford such freezing.
hello @Spikhalskiy, I appreciate a lot your kind words. However I want to reassure you that we'll never break compatibility in order to remove the slave word. The way the word slave will be removed is because as we add new APIs for other reasons, that would break compatibility anyway, we will replace the terms. The most two outstanding examples, for instance, are the INFO and ROLE command.
INFO is terrible for its own reasons. It is very likely that in one or two years, who knows, we'll focus on providing a new command as a replacement. We'll take INFO around for years, with the old terminology to be backward compatible. Eventually, when everybody moved to the new command, that will be able to emit information in a much more parsable format, without outputting all-or-nothing about given metrics, and so forth, we'll deprecate INFO and we may eventually remove it, once it is already totally abandonware.
The same with the ROLE command. We'll change it only when something new will be available. Probably ROLE will not change implementation even with RESPv3, because RESP itself upgraded does not change the fact that clients are expecting "slave", and this is a very rarely used command if not for tooling / monitoring / testing, so it's not a big deal we have a single reference there. However I expect soon or later, that we'll deprecate ROLE anyway, and instead provide a command which is better and can show, for instance, the current replication chain of the instance, the current ID, the secondary replication ID, and so forth. So ROLE will probably still be supported for years, and will be eventually removed.
So the "slave" word in APIs will be removed just as a side effect that for all the new APIs we'll pick new names. And eventually, after many years, old APIs will be deprecated. I wanted to give a signal here to certain polite people that even if are not activist and don't attack anyone, still felt this to be important. However I believe that a balanced signal is to change what is possible to change without making the life harder to everybody else. And the result is the work you can say into unstable right now. It's a lot less likely that an user will see "slave" using Redis. At the same time, everything is backward compatible.
Fact statement. More people here are objecting the change…
@adah1972 that's not a majority thing. The point for me was, is that just a very small part of very vocal activists? Nope, a large (not majority) percentage of Redis users not having to do anything with the activists driving attacks or alike are convinced that this should be changed (even if I don't agree myself). So, is it possible to change it so that others that don't want any change are not affected negatively? Mostly yes -> lets' do it.
Strongly recommended to zhu/cong !!!!!
Extreme Political Correctness!!!!
Hi Salvatore,
I appreciate your kind response and explanation.
Granted, this change might not harm much the people who oppose this change. However, you might be setting a dangerous precedent that an F/OSS project changes its terminology purely due to political pressure. (Yes, I read your words that ‘outside of the activists circle it is clear that there are people that are starting to feel a discomfort in using a given terminology’, but it is still political.) Being in China, like @timurb, I feel very uncomfortable about changing this terminology. Is our discomfort less worthy than that of the people you mentioned? ;-)
By the way, the news about this change is widely reported in China. Literally, I find zero support for making this change among the Chinese IT communities. I read maybe a hundred comments about the news, and not even a single one agreed with the change. Everyone was laughing at it and poking fun with it. Perhaps it is not surprising given that we programmers in China are extremely anti-political-correctness.
I guess the terminology issue is really a US-specific thing. Or, at least, a culture-dependent thing. It seems you are offending some people whether you are making this change or not, sadly…
Dear creator and contributors of Redis, please don't waste your precious time on leftists' political opinions.
I see nothing good from Redis' point of view. We are engineers, not left-wing politicians. Our responsibility is to ensure that Redis works well, not to worry if there are sensitive words that may offend someone in the organization. For those who are not happy about the naming, it's ok to maintain your own version. If you think it's too troublesome for yourself to do it or you simply can't do it, it's your own problem. I feel offended that you people escalated this issue. Redis shouldn't take the risk for your delicate personal feelings.
First of all
- Word usage moral
The meaning of one word changes in different environment or context.
It is definitely not immoral in the way redis use the word "slave". - Bully someone to do a good deed
It is like forcing somebody to donate.
@antirez
I know You are under deep pressure because you are in the position to make this decision. People will judge no matter what you do. As far as I know, there are a lot people will support you no matter what decision you make, just like me.
My silly a advice, just
consider it as a new feature to make some people happy, just like acknowledge, cluster or another data type.
no gru + minion?
:(
Idiocy walks the planet.
Maybe we should liberate a process, instead of 'kill' one
Совсем уже ебанулись.
Don't follow for polit correctness idiots.
They are just idiots without any technical experience (like a trolls).
Well,well,It's that means only left-wings people can be engineers?
It's Discrimination！！！
Hello, I'm from Russia, I understand that some people do not like the word 'slave', but please remember that by far not 100% people belong to cultures which had slavery. So, the percent of people who are really affected is much less than the percent of noise from them.
In some languages some other word, which you use instead of master/slave, may sound strange. In Russian there is a word that sounds exactly as 'replica' and has an a bit different usage/meaning.
If you start using the word 'Replica', than my language will get a new anglicism. It's a trash for language to have 2 completely different meanings of one word, when one meaning is a native and another is not.
People who suggests such silly changes do not respect the right of other people to keep their mother tongue free from not-native words :-)
Of course, that's not a really important problem and is a joke, but changing widely used terminology is so silly.
As long as in a few years we will not have androids complaining about the term REPLICA, it's ok!
Those PC idiots can suck it , fuxking cry baby
Maybe we should liberate a process, instead of 'kill' one
Do euthanasia to the process...
If that'll cause problems, just don't do so. There's no point in this, there's no gain from this. SJWs are going to be SJWs until the trend hops off the train but these changes will in many ways affect actual projects of actual businesses.
Today you bend under "master and slave are discriminating terms", tomorrow they'll force you to go from binary tree to non-binary tree since the first is considered digitist nowadays.
"Master" and "slave" are just terms. No use in renaming them, they have no effect on product and on third world's slavery issues at all. They are just terms, not a single master node ever hit its slave node, nor any slave node have ever been displeased of being controlled. ¯\_(ツ)_/¯
Upd: If they want their terminology, they're free to write whichever project they want. Messing with others' stuff like this (without any usable positive change) is at least rude and at most just retarded.
a large (not majority) percentage of Redis users not having to do anything with the activists driving attacks or alike are convinced that this should be changed (even if I don't agree myself).
According to the emoji reactions to your original post (I see 690 thumbs down + confused; and 97 happy smileys), I do not see ‘a large percentage’. This ‘vote’ may be biased, but it is still kind of a vote, without better data. The vast majority are saying No.
So, is it possible to change it so that others that don't want any change are not affected negatively?
According the negative reaction to the change, I would say No. You would please some people, but in the meantime upset many others. Please do not forget this is not a technical change, and its sole purpose is to make some people happy. Do you still want to push out a change that makes 12% of people happier and 88% of people sadder, seriously—which even you yourself do not agree?
Python is also doing this, disappointing.
https://www.reddit.com/r/programming/comments/9f5t63/after_redis_python_is_also_going_to_remove/
Guys, I can't see any sense in statement "master-slave terminology is horrible". This terminology is not about slavery, but about mechanisms that communicate in some particular way.
Just to clarify, slavery is terrible fact of history, but the fact that political correctness tries to impact on different spheres of life (including even engineering) is terrible as well.
Leave master-slave as is, it just a terminology without any hidden meaning!
@adah1972 The problem that it's a coordinated attack. Major projects already made the changes and they were silently merged with closed discussions like here: facebook/react#13604 python/cpython#9101
There is no reason for Redis to stay the ground if the current society became so weak that they ready to do anything to don't confront with loud minorities that can be offended by any random thing. Other industries at least raise discussions and not always decide to implement changes. For example, there is pretty active discussions around feminism and when it becomes extremism. Tech appeared to be a super weak community (weakest that other) that ready to be shut up like in such voted down and closed threads across github and accept the external inaccurate changes to pretty stable abstract scientific language, projects etc.
If this changes make sense, than my insults to Google's TesorFlow official site is make sense as well. I have orange hairs, and i was an object of jokes in my childhood because of my hairs and this site humiliates me by using orange theme on their site. It's not correct to apply orange theme on you site.
Developers MUST stay around from thats terrible discussions.
If they will continue to accept all "politcorrect" changes, SJW will not be stopped.
SJW will terrorize opensource community more and more and more.
Because all of you surrendered.
SJW is terrorists of 21 century.
Everyone who support they - terrorists too.
m
If you start using the word 'Replica', than my language will get a new anglicism. It's a trash for language to have 2 completely different meanings of one word, when one meaning is a native and another is not.
People who suggests such silly changes do not respect the right of other people to keep their mother tongue free from not-native words :-)
Of course, that's not a really important problem and is a joke, but changing widely used terminology is so silly.
indeed.
Buttana di Maria 'mmaculata, ma dicemu vero? C'a'mu a fari???
I'm a great BDSM lover and I would be really offended if the terminology had to be changed.
Those are just bullies. In this case, a Linus Torvalds - like response for these bullies would be much appreciated on the topic.
What is this discussion about?
When people are slaves that's bad. When Redis process is slave that's… what? Do you think it suffers? Should we start pay it some money for it's work?
What will be changed if we will call it with some other word?
What are you thinking about black color in CSS?
Looks like we are SJW slaves
With this change, you begin to infringe on the rights of BDSM lovers
If you're affected by the Twitter poll, know that it's possible that the majority of Redis users were just busy with their jobs and unaware of said poll, while those so called "activist" got nothing better to do and teaming up in arms to vote for the changes.
Let's close Twitter instead.