Hello everyone,
After discussing the inclusive language topic with the core Nmstate
team and listening to the NetworkManager team suggestions, we have
decided to go to use of the word "ports" for the API in replacement of
"slaves" as this is the only occurrence that needs to be changed in
the public API. This decision has been taken because VLAN is already
using "parent/child" and it could be a port of a bridge so it will
cause confusion.
The idea is to use "port" because team and linux bridge interfaces are
using it currently, too. The change will only be needed on bond and
ovs-bridge interfaces. On the API there is no mention of "master".
Therefore, no change is needed on that.
On the internal code, “master” will be replaced with “controller”.
The plan action is:
1. Add the new words to the API and mark as deprecated the old ones.
That means the users will be able to use the old one but they are
going to get a warning.
2. Replace the words in the internal code.
3. In the future, we are going to remove the old words. There is not a
date, yet, but please move to the new terms now..
4. If there is any agreement/standard in the future, we are going to
consider adopting the proposed new terms.
Thank you for the hard work and your interest in discussing this. We
really appreciate all your different perspectives and we can continue
this discussion on the kernel or IEEE/IETF.
Fernando.
On Wed, Sep 2, 2020 at 3:43 PM Jarod Wilson <jarod(a)redhat.com> wrote:
On Wed, Sep 2, 2020 at 5:22 AM Till Maas <till(a)redhat.com> wrote:
>
> Hi,
>
> Am Di., 1. Sept. 2020 um 22:04 Uhr schrieb Jarod Wilson <jarod(a)redhat.com>:
> >
> > On Tue, Sep 1, 2020 at 3:43 PM Fernando Fernandez Mancera
> > <ferferna(a)redhat.com> wrote:
> > >
> > > Hello again!
> > >
> > > I am considering all the votes to list shared with you recently as no
> > > one proposed new words. Please, send your votes to the mailing list,
> > > you have until Friday 8.00 AM UTC :-)
> > >
> > > P.S: I am considering the votes already sent, so there is no need to
> > > send them again.
> >
> > I intend to go with either bundle/cable or parent/child for the kernel
> > bonding driver, partially because they're the exact same lengths as
> > master/slave, and make some degree of sense. I'd leave trunk and port
> > off the list of options, because VLAN uses trunk quite a bit, and the
> > bonding 802.3ad code already uses port. Probably leaning towards
> > parent/child, since a bond isn't necessarily a bundle of cables. The
> > bigger issue than actual naming is not breaking anyone's userspace,
> > which unfortunately means quite a bit can NOT be changed. Secondary to
> > that, is not making life hell for -stable kernel tree maintainers
> > trying to backport from a bonding driver with new terminology in use.
>
> I Hope that if we choose parent/child here, the kernel will also it in
> the future. :-)
Hm. I was not aware of vlan's usage of parent as well... I've got
mixed opinions on whether stacked devices should all use similar
naming conventions or device-specifc ones. There's also an argument to
be made that we'd muddy things with processes, which all have parents
and children as well. Not sure how familiar others are with the movie
Despicable Me, but the idea of using boss/minion amuses me. Probably
too much of a stretch to use Gru instead of boss, but think of the
bonding slides you could do, talking about how minions are managed. :)
Now that I've muddied the waters even further... Fwiw, It doesn't look
like parent is used at all in either the vlan or vxlan drivers
in-kernel.
> > Note: there's also an open bugzilla for this issue, specific to the
> > bonding driver.
>
> what's the ID?
I believe it's marked as an internal bug, so some folks may not be
able to access it, but here it is:
https://bugzilla.redhat.com/show_bug.cgi?id=1857405
--
Jarod Wilson
jarod(a)redhat.com