PowerDNS
Remove archaic or offensive spelling (master, slave)
- Program: Authoritative, Recursor, dnsdist
- Documentation
- Issue type: Feature request
Short description
Remove the archaic or offensive spelling like super-master, master or slave. there are better words for naming these entities.
Usecase
Use a language which is less offensive or archaic
Description
Replace the words like super-master, master or slave with a new set of namings. a few examples:
- Primary / Secondary
- Parent / Child
Note: I searched for a similiar or same issue through the issue tracker but could find sth. I only found a PR which removes some spelling errors but not those words. If there was a discussion or issue earlier which i didn't see, please point me in the right direction.
Contribution: I am here to help and want to contribute the changes for this issue.
I hope DNS server vendors can agree on terms, e.g. by consulting draft-knodel-terminology-02. ISC implemented the terms primary and secondary for BIND9. In order to not break configurations until much later releases these are currently aliased to master and slave respectively.
E.g. from Bv9ARM:
A primary zone has a master copy of the data for the zone and is able to provide authoritative answers for it. Type master is a synonym for primary.
Yes, using primary and secondary makes sense. We do need to invent something for 'supermaster' then (https://en.wiktionary.org/wiki/superprimary won't fly).
We also have several instances of 'blacklist' and 'whitelist', those should be easy to replace by 'blocklist', 'allowlist' or perhaps in some cases 'ignorelist' or 'droplist'.
The main technical (and user-impacting) challenge is the database schemas (they contain a supermasters table and a domains.masters column) and database contents (domains.type is currently expected to hold MASTER or SLAVE [or NATIVE]). For reading database contents, we should make sure we parse the type into an Enum as quickly as possible to avoid having to distribute the list of aliases (primary=master etc.) all over the code base (#9280 improved on this already).
The other 'user-facing' challenge is the HTTP API. I expect we can introduce aliases there as well on the input side, but the output side is tricker. Ideas for a decent migration strategy are welcome. Perhaps we can duplicate the masters field for a while?
One proposal received privately was to introduce a gsql backend setting primary-word or similar that would, for now, default to master so that existing SQL schemas keep working. Once that is introduced, we can slide towards better wording in the DB schemas in a few releases.
For the recursor, it looks like we have a few Lua config file statements, such as rpzMaster, that could pretty easily grow an alias.
I've ignored user-invisible changes to the code in here; other than making backports hard, those should be fairly easy.
Did I miss anything?
I much prefer allow/deny over allow/block (it's pretty much standard nomenclature in many things already) so allowlist and denylist would make most sense to me.
We do need to invent something for 'supermaster' then (https://en.wiktionary.org/wiki/superprimary won't fly). Supermaster and superslave was never self-describing. So what about: auto-provisioning-of-slave-zone-on-notify=yes/no, or short: auto-provision=yes/no
For the table name: autoprovisionprimaries (a bit long :-()
For the table name: autoprovisionprimaries (a bit long :-()
autoprimaries then?
slave currently causes confusion in some users that have RDBMS replication (i.e. a 'MySQL slave'). Proposal: while we're here, rename slave to xrf-secondary and master to xfr-primary or perhaps send-notifies.
I'd rather send-notify-messages.
rfc 1996 3 calls it 'NOTIFY Message'
The advantages:
- it avoids English stemming problems (both searching and spelling) of
notify - it still indicates that it's plural
- it explains what/how it's doing
If we go with send-notify-messages, we need to do something (larger) to slave-renotify.
Otherwise it's going to be really confusing to say:
- send-notify-messages=no
- xfr-secondary=yes
- xfr-secondary-renotify=yes # but we already turned off notify above!
Similarly, using accept-notify-messages or so for xfr-secondary would make this even worse:
- send-notify-messages=no
- accept-notify-messages=yes
- accept-notify-messages-and-renotify=yes # now what
In #9669 I decided to keep it simple - master becomes primary, slave becomes secondary, other options with those words in them are renamed accordingly, except slave-cycle-interval which always was about both primaries and secondaries, so I renamed that to replication-cycle-interval. Comments on this set of changes welcome on #9669.
Externally visible stuff (docs, settings) are done for recursor. Internally (code), we still need to rename stuff.
More references:
- https://www.theregister.com/2021/03/01/splunk_unbiased_documentation_guide/
- https://docs.splunk.com/Documentation/StyleGuide/current/StyleGuide/Inclusivity
#9969 ( auth pdns.conf, pdnsutil, pdns_control: modern aliases for master/slave #9669 ) is merged. Remaining (auth) work:
- HTTP API
- constants, enums, source file names
- db schema
- db contents (metadata)
- going through all word usages in doc text
- log messages
Any phase of this transition is also a good opportunity to change wrong uses of the word 'domain' to the more accurate 'zone'.
Specifically, for auth-4.5.0 I want to change domainmetadata-cache-ttl to zone-metadata-cache-ttl.
I have rudely put the milestone on auth-4.5.0-alpha1 for this until I do that one.
From a code source perspective we are done. But both the DB schemas and the REST APIs still use the old names. The docs also are not completely rewritten.
Offended by technical terms like master/slave?! Jeez! This generation of soft cry babies! lol! Find a hobby. “Those who cannot remember the past are condemned to repeat it.”
