Re: Replacing master/slave terminology

On Wed, Jun 10, 2020 at 8:01 PM Jeffrey Altman <[email protected]>
wrote:

> For Heimdal, the term "slave" is part of the both the iprop process name
> and command line switches for the iprop_master.  Changing these could
> adversely impact end user deployments that are not expecting their
> configuration scripts and packaging to break.
>

People installing by hand aside, isn't this more of a vendor packaging
issue? They deal with changes like this pretty regularly.

Can the switch to iprop_master can be deprecated but left in place, and
ipropd-slave linked to ipropd-replica and similarly deprecated?


> As a real world example, in 2011 the IETF deprecated the use of AFSDB
> records in favor of SRV records for AFS services.  This was an official
> standardization action that took more than a year to complete.  It has
> been nearly a decade and by my most recent inventory nearly 2/3 of AFS
> cells are still configured with AFSDB records and only 40% have SRV
> records.  Approximately five percent support both.  As a result it has
> been impossible to even consider removing the support for AFSDB records
> and the additional delays that result from trying one and falling back
> to the other.
>

I'm not suggesting removing support, simply for providing a path forward.

The term "master" applies to the database not the server.   The question
> is whether or not the answer to a query is definitive.  All of the KDCs
> can serve data from the "master" database.   The client needs to know
> that it should retry against another server when it can determine that
> the database isn't a "master" as a noun; its "master" as an adjective.
> Where the use of "master" indicates being an expert, principal or
> instructor.
>

This seems like reasonable framing to me.


> Heimdal's documentation should be rewritten to remove the master-slave
> relationship.  If and when there is ever a volunteer to perform that
> work along with all of the other changes that Heimdal's documentation
> requires I will happily merge the pull request.
>

I'm glad to hear that these changes will be accepted. I'll have a look and
see what the scope would be.

Thanks,
--nate
________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos