Hi Jarod,

we are currently exploring better names for the interfaces used in bonding etc. for our network configuration tools in userspace. Ideally, we would like to use the same words that the kernel will eventually use. Since you started a discussion in https://www.spinics.net/lists/netdev/msg668079.html I am wondering if there is already some consensus about which words to use. You can find our ideas in the quote. What are your thoughts?

Thanks Till

Am Mo., 24. Aug. 2020 um 09:58 Uhr schrieb Till Maas till@redhat.com:

Hi,

Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com:

...

Hi,

I would like to suggest we deprecate our use of `master/slave` in nmstate project.

And switching to these terminologies for interface relationship in the coming new release of nmstate-0.4.0:

• For bond/team/bridge:
  • controller/subordinate # For bridge, we can also use controller/port.

having shorter words would be nice, maybe

trunk/leg base/leg

base/dell mesa/dell base/vale

bulk/part

...

• For VLAN/VxLAN:
  • parent/child
  • base/child # Current API using `base-iface`, no need to change

Some other suggestions: base/apex mesa/apex

base/head trunk/head

The trunk interface of eth1 is bond0 eth1 is a leg of the bridge br0 eth1 is a leg of an base interface eth1 is a dell interface of br0 (probably not so nice because of the confusion with the manufacturer) eth1 is a vale interface of br0 eth1 is a limb of br0 eth1 is a leg of br0 br0 is the trunk for eth1

eth1 is a part interface of the br0 bulk interface

the base of VLAN eth1.100 is eth1 eth1.100 is an apex interface of eth1 eth1.100 is a head of eth1 eth1 is the trunk interface for eth1.100. eth1 is the base interface for eth1.100. eth1 is the trunk for eth1.100 eth1.100 is a limb of eth1 eth1.100 is an arm of eth1

These seem to be my current favorites: leg/trunk/head limb/trunk/limb

Limb could be used both for the interfaces included in a bridge or a bond. Not sure, if they need to have different identifiers.

...

For example:

• The `controller` of eth1 is bond0 and `controller_type` is bond
• The br0 is `controller` of eth1
• The eth1 is `port` of bridge br0 or `subordinate` of bridge br0
• The eth1 is `subordinate` of bond0
• The VLAN eth1.100 is child of eth1
• The base interface of eth1.100 is eth1
• The parent of VLAN eth1.100 is eth1
• The VLAN eth1.100 is child of eth1

I am not English native speaker, please kindly help on this if you have better ideas.

Thank you very much!

Thank you for moving this forward!

Till

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote:

Hi,

Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com:

...

Hi,

I would like to suggest we deprecate our use of `master/slave` in nmstate project.

And switching to these terminologies for interface relationship in the coming new release of nmstate-0.4.0:

• For bond/team/bridge:
  • controller/subordinate # For bridge, we can also use controller/port.

having shorter words would be nice, maybe

trunk/leg base/leg

base/dell mesa/dell base/vale

bulk/part

...

• For VLAN/VxLAN:
  • parent/child
  • base/child # Current API using `base-iface`, no need to change

Some other suggestions: base/apex mesa/apex

base/head trunk/head

Those are a little bit confusing for me. I expect both "base" and "head" would replace "master".

I've been thinking on this and it would be good to use only one option for codebase, i.e using the same terms for all kind of interfaces. For the exposed API, I would not change VLAN/VXLAN as we are already using base/child terms. For other interfaces I noticed that we are mixing up "slaves" and "ports", I suggest to unify it into a generic one. IMO, the most generic are "controller/subordinate".

If we agree on the generic word, I would use them for the whole codebase.

What do you think? Thanks!

The trunk interface of eth1 is bond0 eth1 is a leg of the bridge br0 eth1 is a leg of an base interface eth1 is a dell interface of br0 (probably not so nice because of the confusion with the manufacturer) eth1 is a vale interface of br0 eth1 is a limb of br0 eth1 is a leg of br0 br0 is the trunk for eth1

eth1 is a part interface of the br0 bulk interface

the base of VLAN eth1.100 is eth1 eth1.100 is an apex interface of eth1 eth1.100 is a head of eth1 eth1 is the trunk interface for eth1.100. eth1 is the base interface for eth1.100. eth1 is the trunk for eth1.100 eth1.100 is a limb of eth1 eth1.100 is an arm of eth1

These seem to be my current favorites: leg/trunk/head limb/trunk/limb

Limb could be used both for the interfaces included in a bridge or a bond. Not sure, if they need to have different identifiers.

...

For example:

• The `controller` of eth1 is bond0 and `controller_type` is bond
• The br0 is `controller` of eth1
• The eth1 is `port` of bridge br0 or `subordinate` of bridge br0
• The eth1 is `subordinate` of bond0
• The VLAN eth1.100 is child of eth1
• The base interface of eth1.100 is eth1
• The parent of VLAN eth1.100 is eth1
• The VLAN eth1.100 is child of eth1

I am not English native speaker, please kindly help on this if you have better ideas.

Thank you very much!

Thank you for moving this forward!

Till

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

Hi,

Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com:

...

Hi,

I would like to suggest we deprecate our use of `master/slave` in nmstate project.

And switching to these terminologies for interface relationship in the coming new release of nmstate-0.4.0:

• For bond/team/bridge:
  • controller/subordinate # For bridge, we can also use controller/port.

having shorter words would be nice, maybe

trunk/leg base/leg

base/dell mesa/dell base/vale

bulk/part

...

• For VLAN/VxLAN:
  • parent/child
  • base/child # Current API using `base-iface`, no need to change

Some other suggestions: base/apex mesa/apex

base/head trunk/head

Those are a little bit confusing for me. I expect both "base" and "head" would replace "master".

Interesting. This might be because I did not think about the old analogy where one interface has power over the other but more like how they are arranged.

Bond interfaces are built on top of other interfaces, making the other interfaces something at the bottom (like legs) and the bond interface the trunk or base. Since VLAN interfaces are also built on top of other interfaces, even on bond interfaces, this makes them another top layer which is the head. But since there could be multiple VLAns, arms might make more sense and then both arms and legs are limbs.

I've been thinking on this and it would be good to use only one option for codebase, i.e using the same terms for all kind of interfaces. For the exposed API, I would not change VLAN/VXLAN as we are already using base/child terms. For other interfaces I noticed that we are mixing up "slaves" and "ports", I suggest to unify it into a generic one. IMO, the most generic are "controller/subordinate".

If we agree on the generic word, I would use them for the whole codebase.

What do you think? Thanks!

I am not sure if the power structure is the best analogy, here. Does a bond/bridge interface really control its subordinate interfaces? Maybe it also does not matter that much, given that at some point the words will be defined by usage. However, using long words might not stick since people are lazy. A shorter alternative might be top interface/sub interface.

Thanks Till

...

The trunk interface of eth1 is bond0 eth1 is a leg of the bridge br0 eth1 is a leg of an base interface eth1 is a dell interface of br0 (probably not so nice because of the confusion with the manufacturer) eth1 is a vale interface of br0 eth1 is a limb of br0 eth1 is a leg of br0 br0 is the trunk for eth1

eth1 is a part interface of the br0 bulk interface

the base of VLAN eth1.100 is eth1 eth1.100 is an apex interface of eth1 eth1.100 is a head of eth1 eth1 is the trunk interface for eth1.100. eth1 is the base interface for eth1.100. eth1 is the trunk for eth1.100 eth1.100 is a limb of eth1 eth1.100 is an arm of eth1

These seem to be my current favorites: leg/trunk/head limb/trunk/limb

Limb could be used both for the interfaces included in a bridge or a bond. Not sure, if they need to have different identifiers.

...

For example:

• The `controller` of eth1 is bond0 and `controller_type` is bond
• The br0 is `controller` of eth1
• The eth1 is `port` of bridge br0 or `subordinate` of bridge br0
• The eth1 is `subordinate` of bond0
• The VLAN eth1.100 is child of eth1
• The base interface of eth1.100 is eth1
• The parent of VLAN eth1.100 is eth1
• The VLAN eth1.100 is child of eth1

I am not English native speaker, please kindly help on this if you have better ideas.

Thank you very much!

Thank you for moving this forward!

Till

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com:

...

Hi,

I would like to suggest we deprecate our use of `master/slave` in nmstate project.

And switching to these terminologies for interface relationship in the coming new release of nmstate-0.4.0:

• For bond/team/bridge:
  • controller/subordinate # For bridge, we can also use controller/port.

having shorter words would be nice, maybe

trunk/leg base/leg

base/dell mesa/dell base/vale

bulk/part

...

• For VLAN/VxLAN:
  • parent/child
  • base/child # Current API using `base-iface`, no need to change

Some other suggestions: base/apex mesa/apex

base/head trunk/head

Those are a little bit confusing for me. I expect both "base" and "head" would replace "master".

Interesting. This might be because I did not think about the old analogy where one interface has power over the other but more like how they are arranged.

Bond interfaces are built on top of other interfaces, making the other interfaces something at the bottom (like legs) and the bond interface the trunk or base. Since VLAN interfaces are also built on top of other interfaces, even on bond interfaces, this makes them another top layer which is the head. But since there could be multiple VLAns, arms might make more sense and then both arms and legs are limbs.

...

I've been thinking on this and it would be good to use only one option for codebase, i.e using the same terms for all kind of interfaces. For the exposed API, I would not change VLAN/VXLAN as we are already using base/child terms. For other interfaces I noticed that we are mixing up "slaves" and "ports", I suggest to unify it into a generic one. IMO, the most generic are "controller/subordinate".

If we agree on the generic word, I would use them for the whole codebase.

What do you think? Thanks!

I am not sure if the power structure is the best analogy, here. Does a bond/bridge interface really control its subordinate interfaces? Maybe it also does not matter that much, given that at some point the words will be defined by usage. However, using long words might not stick since people are lazy. A shorter alternative might be top interface/sub interface.

Yes, that is true. It would be nice to use a shorter word.. maybe "parent/child"? As parents have power over their childs.. Not sure. About interface/subinterface, I find them very lazy, "interface" term is all over the codebase so it could be very confusing for us, IMO.

I also like "base/lag"-

Thanks!

...

Thanks Till

...

...

The trunk interface of eth1 is bond0 eth1 is a leg of the bridge br0 eth1 is a leg of an base interface eth1 is a dell interface of br0 (probably not so nice because of the confusion with the manufacturer) eth1 is a vale interface of br0 eth1 is a limb of br0 eth1 is a leg of br0 br0 is the trunk for eth1

eth1 is a part interface of the br0 bulk interface

the base of VLAN eth1.100 is eth1 eth1.100 is an apex interface of eth1 eth1.100 is a head of eth1 eth1 is the trunk interface for eth1.100. eth1 is the base interface for eth1.100. eth1 is the trunk for eth1.100 eth1.100 is a limb of eth1 eth1.100 is an arm of eth1

These seem to be my current favorites: leg/trunk/head limb/trunk/limb

Limb could be used both for the interfaces included in a bridge or a bond. Not sure, if they need to have different identifiers.

...

For example:

• The `controller` of eth1 is bond0 and `controller_type` is bond
• The br0 is `controller` of eth1
• The eth1 is `port` of bridge br0 or `subordinate` of bridge br0
• The eth1 is `subordinate` of bond0
• The VLAN eth1.100 is child of eth1
• The base interface of eth1.100 is eth1
• The parent of VLAN eth1.100 is eth1
• The VLAN eth1.100 is child of eth1

I am not English native speaker, please kindly help on this if you have better ideas.

Thank you very much!

Thank you for moving this forward!

Till

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

On Thu, Aug 27, 2020 at 11:49:01AM +0200, Fernando Fernandez Mancera wrote:

Hello!

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers. https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

I propose to use:

"base/worker" or "main/worker".

My 2 cents: 'main/worker' sounds nicer and more consistent.

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

Thanks, Antonio.

Another idea for the naming.

If we consider something like:

bond0: - eth0 - eth1 - eth2 - eth3

bond0.vlan1 bond0.vlan2

etc,

- What about calling the physical interfaces "eth0-3" "members" of bond0? - What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

...

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers.

https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

...

I propose to use:

"base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

...

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez

Mancera

...

...

...

...

ferferna@redhat.com:

...

On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com

wrote:

...

...

...

...

...

> > Hi, > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge <

fge@redhat.com>:

...

...

...

...

...

> > > > Hi, > > > > I would like to suggest we deprecate our use of

`master/slave` in

...

...

...

...

...

> > nmstate project. > > > > And switching to these terminologies for interface

relationship in

...

...

...

...

...

> > the coming new release of nmstate-0.4.0: > > > > * For bond/team/bridge: > > * controller/subordinate > > # For bridge, we can also use controller/port. > > having shorter words would be nice, maybe > > trunk/leg > base/leg > > base/dell > mesa/dell > base/vale > > bulk/part > > > > > * For VLAN/VxLAN: > > * parent/child > > * base/child > > # Current API using `base-iface`, no need to change > > Some other suggestions: > base/apex > mesa/apex > > base/head > trunk/head

Those are a little bit confusing for me. I expect both "base" and "head" would replace "master".

Interesting. This might be because I did not think about the old analogy where one interface has power over the other but more like

how

...

...

...

...

they are arranged.

Bond interfaces are built on top of other interfaces, making the

other

...

...

...

...

interfaces something at the bottom (like legs) and the bond

interface

...

...

...

...

the trunk or base. Since VLAN interfaces are also built on top of other interfaces, even on bond interfaces, this makes them another

top

...

...

...

...

layer which is the head. But since there could be multiple VLAns,

arms

...

...

...

...

might make more sense and then both arms and legs are limbs.

...

I've been thinking on this and it would be good to use only one

option

...

...

...

...

...

for codebase, i.e using the same terms for all kind of

interfaces. For

...

...

...

...

...

the exposed API, I would not change VLAN/VXLAN as we are already

using

...

...

...

...

...

base/child terms. For other interfaces I noticed that we are

mixing up

...

...

...

...

...

"slaves" and "ports", I suggest to unify it into a generic one.

IMO,

...

...

...

...

...

the most generic are "controller/subordinate".

If we agree on the generic word, I would use them for the whole

codebase.

...

...

...

...

...

What do you think? Thanks!

I am not sure if the power structure is the best analogy, here.

Does a

...

...

...

...

bond/bridge interface really control its subordinate interfaces?

Maybe

...

...

...

...

it also does not matter that much, given that at some point the

words

...

...

...

...

will be defined by usage. However, using long words might not stick since people are lazy. A shorter alternative might be top interface/sub interface.

Yes, that is true. It would be nice to use a shorter word.. maybe "parent/child"? As parents have power over their childs.. Not sure. About interface/subinterface, I find them very lazy, "interface" term is all over the codebase so it could be very confusing for us, IMO.

I also like "base/lag"-

Thanks!

...

Thanks Till

...

> > > The trunk interface of eth1 is bond0 > eth1 is a leg of the bridge br0 > eth1 is a leg of an base interface > eth1 is a dell interface of br0 (probably not so nice because

of the

...

...

...

...

...

> confusion with the manufacturer) > eth1 is a vale interface of br0 > eth1 is a limb of br0 > eth1 is a leg of br0 > br0 is the trunk for eth1 > > > eth1 is a part interface of the br0 bulk interface > > > the base of VLAN eth1.100 is eth1 > eth1.100 is an apex interface of eth1 > eth1.100 is a head of eth1 > eth1 is the trunk interface for eth1.100. > eth1 is the base interface for eth1.100. > eth1 is the trunk for eth1.100 > eth1.100 is a limb of eth1 > eth1.100 is an arm of eth1 > > > These seem to be my current favorites: > leg/trunk/head > limb/trunk/limb > > Limb could be used both for the interfaces included in a

bridge or a

...

...

...

...

...

> bond. Not sure, if they need to have different identifiers. > > > > > > For example: > > * The `controller` of eth1 is bond0 and `controller_type`

is bond

...

...

...

...

...

> > * The br0 is `controller` of eth1 > > * The eth1 is `port` of bridge br0 or `subordinate` of

bridge br0

...

...

...

...

...

> > * The eth1 is `subordinate` of bond0 > > * The VLAN eth1.100 is child of eth1 > > * The base interface of eth1.100 is eth1 > > * The parent of VLAN eth1.100 is eth1 > > * The VLAN eth1.100 is child of eth1 > > > > I am not English native speaker, please kindly help on this

if you have

...

...

...

...

...

> > better ideas. > > > > Thank you very much! > > Thank you for moving this forward! > > Till > > > > -- > Till Maas > He/His/Him > Associate Manager, Software Engineering > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat:

Grasbrunn,

...

...

...

...

...

> Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Laurie Krebs, Michael

O'Neill,

...

...

...

...

...

> Thomas Savage >

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat:

Grasbrunn,

...

...

...

...

Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

Hi,

This issue has been referenced by the Kernel community here https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/ . That ref also includes other references from several organizations.

My main concern here is that we will diverge from the telco terms which is the source of the current naming using the API. I have not managed to see work on this from IEEE or IETF (e.g. RFC/s proposals). It took centuries for the current technical terms to get stabilized and become a common language for engineers to communicate.

I would prefer to understand if there is any work on this from the standard communities that suggest changes or perhaps already have other naming conventions in place. If there are none, I would go ahead and sync with similar products like OVS which should have the same issues and may have already passed this process.

What I do not prefer to have is a unique Nmstate naming convention which will differ from other telco solutions. If we are talking about internal non-API usage, then anything may work and is easily changeable. But when we look at the API level this may be a serious issue which merits a larger design effort and not just a simple voting.

Thanks, Edy.

On Mon, Aug 31, 2020 at 1:33 PM Fernando Fernandez Mancera < ferferna@redhat.com> wrote:

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

Thanks, Fernando.

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

...

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers.

https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

...

...

...

I propose to use:

"base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

...

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com

wrote:

...

...

...

...

...

> > Hi, > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez

Mancera

...

...

...

...

...

> ferferna@redhat.com: > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com

wrote:

...

...

...

...

...

> > > > > > Hi, > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge <

fge@redhat.com>:

...

...

...

...

...

> > > > > > > > Hi, > > > > > > > > I would like to suggest we deprecate our use of

`master/slave` in

...

...

...

...

...

> > > > nmstate project. > > > > > > > > And switching to these terminologies for interface

relationship in

...

...

...

...

...

> > > > the coming new release of nmstate-0.4.0: > > > > > > > > * For bond/team/bridge: > > > > * controller/subordinate > > > > # For bridge, we can also use controller/port. > > > > > > having shorter words would be nice, maybe > > > > > > trunk/leg > > > base/leg > > > > > > base/dell > > > mesa/dell > > > base/vale > > > > > > bulk/part > > > > > > > > > > > * For VLAN/VxLAN: > > > > * parent/child > > > > * base/child > > > > # Current API using `base-iface`, no need to

change

...

...

...

...

...

> > > > > > Some other suggestions: > > > base/apex > > > mesa/apex > > > > > > base/head > > > trunk/head > > > > Those are a little bit confusing for me. I expect both "base"

and

...

...

...

...

...

> > "head" would replace "master". > > Interesting. This might be because I did not think about the old > analogy where one interface has power over the other but more

like how

...

...

...

...

...

> they are arranged. > > Bond interfaces are built on top of other interfaces, making

the other

...

...

...

...

...

> interfaces something at the bottom (like legs) and the bond

interface

...

...

...

...

...

> the trunk or base. Since VLAN interfaces are also built on top

of

...

...

...

...

...

> other interfaces, even on bond interfaces, this makes them

another top

...

...

...

...

...

> layer which is the head. But since there could be multiple

VLAns, arms

...

...

...

...

...

> might make more sense and then both arms and legs are limbs. > > > I've been thinking on this and it would be good to use only

one option

...

...

...

...

...

> > for codebase, i.e using the same terms for all kind of

interfaces. For

...

...

...

...

...

> > the exposed API, I would not change VLAN/VXLAN as we are

already using

...

...

...

...

...

> > base/child terms. For other interfaces I noticed that we are

mixing up

...

...

...

...

...

> > "slaves" and "ports", I suggest to unify it into a generic

one. IMO,

...

...

...

...

...

> > the most generic are "controller/subordinate". > > > > If we agree on the generic word, I would use them for the

whole codebase.

...

...

...

...

...

> > > > What do you think? Thanks! > > I am not sure if the power structure is the best analogy, here.

Does a

...

...

...

...

...

> bond/bridge interface really control its subordinate

interfaces? Maybe

...

...

...

...

...

> it also does not matter that much, given that at some point the

words

...

...

...

...

...

> will be defined by usage. However, using long words might not

stick

...

...

...

...

...

> since people are lazy. A shorter alternative might be top > interface/sub interface. >

Yes, that is true. It would be nice to use a shorter word.. maybe "parent/child"? As parents have power over their childs.. Not

sure.

...

...

...

...

...

About interface/subinterface, I find them very lazy, "interface"

term

...

...

...

...

...

is all over the codebase so it could be very confusing for us,

IMO.

...

...

...

...

...

I also like "base/lag"-

Thanks!

> Thanks > Till > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > eth1 is a leg of the bridge br0 > > > eth1 is a leg of an base interface > > > eth1 is a dell interface of br0 (probably not so nice

because of the

...

...

...

...

...

> > > confusion with the manufacturer) > > > eth1 is a vale interface of br0 > > > eth1 is a limb of br0 > > > eth1 is a leg of br0 > > > br0 is the trunk for eth1 > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > eth1.100 is an apex interface of eth1 > > > eth1.100 is a head of eth1 > > > eth1 is the trunk interface for eth1.100. > > > eth1 is the base interface for eth1.100. > > > eth1 is the trunk for eth1.100 > > > eth1.100 is a limb of eth1 > > > eth1.100 is an arm of eth1 > > > > > > > > > These seem to be my current favorites: > > > leg/trunk/head > > > limb/trunk/limb > > > > > > Limb could be used both for the interfaces included in a

bridge or a

...

...

...

...

...

> > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > For example: > > > > * The `controller` of eth1 is bond0 and

`controller_type` is bond

...

...

...

...

...

> > > > * The br0 is `controller` of eth1 > > > > * The eth1 is `port` of bridge br0 or `subordinate` of

bridge br0

...

...

...

...

...

> > > > * The eth1 is `subordinate` of bond0 > > > > * The VLAN eth1.100 is child of eth1 > > > > * The base interface of eth1.100 is eth1 > > > > * The parent of VLAN eth1.100 is eth1 > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > I am not English native speaker, please kindly help on

this if you have

...

...

...

...

...

> > > > better ideas. > > > > > > > > Thank you very much! > > > > > > Thank you for moving this forward! > > > > > > Till > > > > > > > > > > > > -- > > > Till Maas > > > He/His/Him > > > Associate Manager, Software Engineering > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat:

Grasbrunn,

...

...

...

...

...

> > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael

O'Neill,

...

...

...

...

...

> > > Thomas Savage > > > > > > > > -- > Till Maas > He/His/Him > Associate Manager, Software Engineering > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat:

Grasbrunn,

...

...

...

...

...

> Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Laurie Krebs, Michael

O'Neill,

...

...

...

...

...

> Thomas Savage >

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to

nmstate-devel-leave@lists.fedorahosted.org

...

...

Fedora Code of Conduct:

https://docs.fedoraproject.org/en-US/project/code-of-conduct/

...

...

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:

https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste... _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

Hi,

Am Mo., 31. Aug. 2020 um 12:55 Uhr schrieb Edward Haas edwardh@redhat.com:

Hi,

This issue has been referenced by the Kernel community here. That ref also includes other references from several organizations.

My main concern here is that we will diverge from the telco terms which is the source of the current naming using the API. I have not managed to see work on this from IEEE or IETF (e.g. RFC/s proposals). It took centuries for the current technical terms to get stabilized and become a common language for engineers to communicate.

There is this draft: https://tools.ietf.org/id/draft-knodel-terminology-02.html Not sure how much people are still working on it, seems that the oldest version is from 2018.

What I do not prefer to have is a unique Nmstate naming convention which will differ from other telco solutions. If we are talking about internal non-API usage, then anything may work and is easily changeable. But when we look at the API level this may be a serious issue which merits a larger design effort and not just a simple voting.

Since we are talking about only two words, I believe it is reasonable for anyone to learn that different words are used in other contexts. Since we are talking about preparations for nmstate 1.0.0, the inclusive terms need to be chosen sooner than later to ensure that it can be properly communicated and we can avoid this change after 1.0.0.

Thanks Till

Thanks, Edy.

On Mon, Aug 31, 2020 at 1:33 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

Thanks, Fernando.

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

...

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers. https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

I propose to use:

"base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

...

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote: > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > Hi, > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > ferferna@redhat.com: > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > Hi, > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > nmstate project. > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > * For bond/team/bridge: > > > > > * controller/subordinate > > > > > # For bridge, we can also use controller/port. > > > > > > > > having shorter words would be nice, maybe > > > > > > > > trunk/leg > > > > base/leg > > > > > > > > base/dell > > > > mesa/dell > > > > base/vale > > > > > > > > bulk/part > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > * parent/child > > > > > * base/child > > > > > # Current API using `base-iface`, no need to change > > > > > > > > Some other suggestions: > > > > base/apex > > > > mesa/apex > > > > > > > > base/head > > > > trunk/head > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > "head" would replace "master". > > > > Interesting. This might be because I did not think about the old > > analogy where one interface has power over the other but more like how > > they are arranged. > > > > Bond interfaces are built on top of other interfaces, making the other > > interfaces something at the bottom (like legs) and the bond interface > > the trunk or base. Since VLAN interfaces are also built on top of > > other interfaces, even on bond interfaces, this makes them another top > > layer which is the head. But since there could be multiple VLAns, arms > > might make more sense and then both arms and legs are limbs. > > > > > I've been thinking on this and it would be good to use only one option > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > base/child terms. For other interfaces I noticed that we are mixing up > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > the most generic are "controller/subordinate". > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > What do you think? Thanks! > > > > I am not sure if the power structure is the best analogy, here. Does a > > bond/bridge interface really control its subordinate interfaces? Maybe > > it also does not matter that much, given that at some point the words > > will be defined by usage. However, using long words might not stick > > since people are lazy. A shorter alternative might be top > > interface/sub interface. > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > "parent/child"? As parents have power over their childs.. Not sure. > About interface/subinterface, I find them very lazy, "interface" term > is all over the codebase so it could be very confusing for us, IMO. > > I also like "base/lag"- > > Thanks! > > > Thanks > > Till > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > eth1 is a leg of the bridge br0 > > > > eth1 is a leg of an base interface > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > confusion with the manufacturer) > > > > eth1 is a vale interface of br0 > > > > eth1 is a limb of br0 > > > > eth1 is a leg of br0 > > > > br0 is the trunk for eth1 > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > eth1.100 is an apex interface of eth1 > > > > eth1.100 is a head of eth1 > > > > eth1 is the trunk interface for eth1.100. > > > > eth1 is the base interface for eth1.100. > > > > eth1 is the trunk for eth1.100 > > > > eth1.100 is a limb of eth1 > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > These seem to be my current favorites: > > > > leg/trunk/head > > > > limb/trunk/limb > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > For example: > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > * The br0 is `controller` of eth1 > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > * The eth1 is `subordinate` of bond0 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > * The base interface of eth1.100 is eth1 > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > better ideas. > > > > > > > > > > Thank you very much! > > > > > > > > Thank you for moving this forward! > > > > > > > > Till > > > > > > > > > > > > > > > > -- > > > > Till Maas > > > > He/His/Him > > > > Associate Manager, Software Engineering > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > > > Thomas Savage > > > > > > > > > > > > > -- > > Till Maas > > He/His/Him > > Associate Manager, Software Engineering > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > Thomas Savage > >

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

---

nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

On Mon, Aug 31, 2020 at 3:40 PM Edward Haas edwardh@redhat.com wrote:

On Mon, Aug 31, 2020 at 2:40 PM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 31. Aug. 2020 um 12:55 Uhr schrieb Edward Haas edwardh@redhat.com:

...

Hi,

This issue has been referenced by the Kernel community here. That ref also includes other references from several organizations.

My main concern here is that we will diverge from the telco terms which is the source of the current naming using the API. I have not managed to see work on this from IEEE or IETF (e.g. RFC/s proposals). It took centuries for the current technical terms to get stabilized and become a common language for engineers to communicate.

There is this draft: https://tools.ietf.org/id/draft-knodel-terminology-02.html Not sure how much people are still working on it, seems that the oldest version is from 2018.

Thanks. Unfortunately I see not decision made and no specific changes that will sync all to the same naming.

...

...

What I do not prefer to have is a unique Nmstate naming convention which will differ from other telco solutions. If we are talking about internal non-API usage, then anything may work and is easily changeable. But when we look at the API level this may be a serious issue which merits a larger design effort and not just a simple voting.

Since we are talking about only two words, I believe it is reasonable for anyone to learn that different words are used in other contexts. Since we are talking about preparations for nmstate 1.0.0, the inclusive terms need to be chosen sooner than later to ensure that it can be properly communicated and we can avoid this change after 1.0.0.

My claim here is that if we do this prematurely we lose consistency and standardization. If there is no standardization yet, at least some that the big players have agreed on, we should not enforce namings which may surprise our users.

In general, we could introduce another inclusive naming without breaking the existing and control it through configuration. The same can be done in the future when something is agreed in the telco community. The configuration just needs to control the reporting, the setting can accept all options. Will that provide a reasonable solution for this goal?

I have tried to find any kind of agreement on which words we should use. The idea is to mark "master/slave" as deprecated in nmstate 1.0.0 so they will not be removed yet. For internal code, it will be removed, does this work for you?

By the way, do you suggest any words? :-)

Thanks! Fernando.

...

Thanks Till

...

Thanks, Edy.

On Mon, Aug 31, 2020 at 1:33 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

Thanks, Fernando.

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

> Looking on the thread it seems we agree on two points: > > * We should use a generic word for codebase and for API VLAN/VXLAN > will user base/parent, as we are already doing. > > * Short words are good so controller/subordinate is too long and > interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

> > IMO, we should follow the kernel terms and we shouldn't create new > terms because it would be hard to understand for maintainers. > https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms... > > I propose to use: > > "base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

> > If there is no complaint on this I will work on this by next week, so > please, share your thoughts. :-) > > Thanks! > Fernando. > > On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera > ferferna@redhat.com wrote: > > > > Sorry, I meant "base/leg". > > > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera > > ferferna@redhat.com wrote: > > > > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > > > ferferna@redhat.com: > > > > > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > > > nmstate project. > > > > > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > > > > > * For bond/team/bridge: > > > > > > > * controller/subordinate > > > > > > > # For bridge, we can also use controller/port. > > > > > > > > > > > > having shorter words would be nice, maybe > > > > > > > > > > > > trunk/leg > > > > > > base/leg > > > > > > > > > > > > base/dell > > > > > > mesa/dell > > > > > > base/vale > > > > > > > > > > > > bulk/part > > > > > > > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > > > * parent/child > > > > > > > * base/child > > > > > > > # Current API using `base-iface`, no need to change > > > > > > > > > > > > Some other suggestions: > > > > > > base/apex > > > > > > mesa/apex > > > > > > > > > > > > base/head > > > > > > trunk/head > > > > > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > > > "head" would replace "master". > > > > > > > > Interesting. This might be because I did not think about the old > > > > analogy where one interface has power over the other but more like how > > > > they are arranged. > > > > > > > > Bond interfaces are built on top of other interfaces, making the other > > > > interfaces something at the bottom (like legs) and the bond interface > > > > the trunk or base. Since VLAN interfaces are also built on top of > > > > other interfaces, even on bond interfaces, this makes them another top > > > > layer which is the head. But since there could be multiple VLAns, arms > > > > might make more sense and then both arms and legs are limbs. > > > > > > > > > I've been thinking on this and it would be good to use only one option > > > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > > > base/child terms. For other interfaces I noticed that we are mixing up > > > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > > > the most generic are "controller/subordinate". > > > > > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > > > > > What do you think? Thanks! > > > > > > > > I am not sure if the power structure is the best analogy, here. Does a > > > > bond/bridge interface really control its subordinate interfaces? Maybe > > > > it also does not matter that much, given that at some point the words > > > > will be defined by usage. However, using long words might not stick > > > > since people are lazy. A shorter alternative might be top > > > > interface/sub interface. > > > > > > > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > > > "parent/child"? As parents have power over their childs.. Not sure. > > > About interface/subinterface, I find them very lazy, "interface" term > > > is all over the codebase so it could be very confusing for us, IMO. > > > > > > I also like "base/lag"- > > > > > > Thanks! > > > > > > > Thanks > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > > > eth1 is a leg of the bridge br0 > > > > > > eth1 is a leg of an base interface > > > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > > > confusion with the manufacturer) > > > > > > eth1 is a vale interface of br0 > > > > > > eth1 is a limb of br0 > > > > > > eth1 is a leg of br0 > > > > > > br0 is the trunk for eth1 > > > > > > > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > > > eth1.100 is an apex interface of eth1 > > > > > > eth1.100 is a head of eth1 > > > > > > eth1 is the trunk interface for eth1.100. > > > > > > eth1 is the base interface for eth1.100. > > > > > > eth1 is the trunk for eth1.100 > > > > > > eth1.100 is a limb of eth1 > > > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > > > > > > > These seem to be my current favorites: > > > > > > leg/trunk/head > > > > > > limb/trunk/limb > > > > > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > > > > > > > > > For example: > > > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > > > * The br0 is `controller` of eth1 > > > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > > > * The eth1 is `subordinate` of bond0 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > * The base interface of eth1.100 is eth1 > > > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > > > better ideas. > > > > > > > > > > > > > > Thank you very much! > > > > > > > > > > > > Thank you for moving this forward! > > > > > > > > > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Till Maas > > > > > > He/His/Him > > > > > > Associate Manager, Software Engineering > > > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > > > > > Thomas Savage > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Till Maas > > > > He/His/Him > > > > Associate Manager, Software Engineering > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > > > Thomas Savage > > > > >

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

---

nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Hi,

Am Mo., 31. Aug. 2020 um 15:40 Uhr schrieb Edward Haas edwardh@redhat.com:

On Mon, Aug 31, 2020 at 2:40 PM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 31. Aug. 2020 um 12:55 Uhr schrieb Edward Haas edwardh@redhat.com:

...

Hi,

This issue has been referenced by the Kernel community here. That ref also includes other references from several organizations.

My main concern here is that we will diverge from the telco terms which is the source of the current naming using the API. I have not managed to see work on this from IEEE or IETF (e.g. RFC/s proposals). It took centuries for the current technical terms to get stabilized and become a common language for engineers to communicate.

There is this draft: https://tools.ietf.org/id/draft-knodel-terminology-02.html Not sure how much people are still working on it, seems that the oldest version is from 2018.

Thanks. Unfortunately I see not decision made and no specific changes that will sync all to the same naming.

...

...

What I do not prefer to have is a unique Nmstate naming convention which will differ from other telco solutions. If we are talking about internal non-API usage, then anything may work and is easily changeable. But when we look at the API level this may be a serious issue which merits a larger design effort and not just a simple voting.

Since we are talking about only two words, I believe it is reasonable for anyone to learn that different words are used in other contexts. Since we are talking about preparations for nmstate 1.0.0, the inclusive terms need to be chosen sooner than later to ensure that it can be properly communicated and we can avoid this change after 1.0.0.

My claim here is that if we do this prematurely we lose consistency and standardization. If there is no standardization yet, at least some that the big players have agreed on, we should not enforce namings which may surprise our users.

In my opinion, Nmstate is free to choose inclusion over standardization. This does not mean that Nmstate is enforcing this for anyone.

In general, we could introduce another inclusive naming without breaking the existing and control it through configuration. The same can be done in the future when something is agreed in the telco community. The configuration just needs to control the reporting, the setting can accept all options.

Since we have constants for everything, users who prefer offensive over inclusive language can probably adjust this easily on their side IMHO. This seems trivial enough that it does not need a config in Nmstate.

Thanks Till

Will that provide a reasonable solution for this goal?

...

Thanks Till

...

Thanks, Edy.

On Mon, Aug 31, 2020 at 1:33 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

Thanks, Fernando.

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

> Looking on the thread it seems we agree on two points: > > * We should use a generic word for codebase and for API VLAN/VXLAN > will user base/parent, as we are already doing. > > * Short words are good so controller/subordinate is too long and > interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

> > IMO, we should follow the kernel terms and we shouldn't create new > terms because it would be hard to understand for maintainers. > https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms... > > I propose to use: > > "base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

> > If there is no complaint on this I will work on this by next week, so > please, share your thoughts. :-) > > Thanks! > Fernando. > > On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera > ferferna@redhat.com wrote: > > > > Sorry, I meant "base/leg". > > > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera > > ferferna@redhat.com wrote: > > > > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > > > ferferna@redhat.com: > > > > > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > > > nmstate project. > > > > > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > > > > > * For bond/team/bridge: > > > > > > > * controller/subordinate > > > > > > > # For bridge, we can also use controller/port. > > > > > > > > > > > > having shorter words would be nice, maybe > > > > > > > > > > > > trunk/leg > > > > > > base/leg > > > > > > > > > > > > base/dell > > > > > > mesa/dell > > > > > > base/vale > > > > > > > > > > > > bulk/part > > > > > > > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > > > * parent/child > > > > > > > * base/child > > > > > > > # Current API using `base-iface`, no need to change > > > > > > > > > > > > Some other suggestions: > > > > > > base/apex > > > > > > mesa/apex > > > > > > > > > > > > base/head > > > > > > trunk/head > > > > > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > > > "head" would replace "master". > > > > > > > > Interesting. This might be because I did not think about the old > > > > analogy where one interface has power over the other but more like how > > > > they are arranged. > > > > > > > > Bond interfaces are built on top of other interfaces, making the other > > > > interfaces something at the bottom (like legs) and the bond interface > > > > the trunk or base. Since VLAN interfaces are also built on top of > > > > other interfaces, even on bond interfaces, this makes them another top > > > > layer which is the head. But since there could be multiple VLAns, arms > > > > might make more sense and then both arms and legs are limbs. > > > > > > > > > I've been thinking on this and it would be good to use only one option > > > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > > > base/child terms. For other interfaces I noticed that we are mixing up > > > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > > > the most generic are "controller/subordinate". > > > > > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > > > > > What do you think? Thanks! > > > > > > > > I am not sure if the power structure is the best analogy, here. Does a > > > > bond/bridge interface really control its subordinate interfaces? Maybe > > > > it also does not matter that much, given that at some point the words > > > > will be defined by usage. However, using long words might not stick > > > > since people are lazy. A shorter alternative might be top > > > > interface/sub interface. > > > > > > > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > > > "parent/child"? As parents have power over their childs.. Not sure. > > > About interface/subinterface, I find them very lazy, "interface" term > > > is all over the codebase so it could be very confusing for us, IMO. > > > > > > I also like "base/lag"- > > > > > > Thanks! > > > > > > > Thanks > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > > > eth1 is a leg of the bridge br0 > > > > > > eth1 is a leg of an base interface > > > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > > > confusion with the manufacturer) > > > > > > eth1 is a vale interface of br0 > > > > > > eth1 is a limb of br0 > > > > > > eth1 is a leg of br0 > > > > > > br0 is the trunk for eth1 > > > > > > > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > > > eth1.100 is an apex interface of eth1 > > > > > > eth1.100 is a head of eth1 > > > > > > eth1 is the trunk interface for eth1.100. > > > > > > eth1 is the base interface for eth1.100. > > > > > > eth1 is the trunk for eth1.100 > > > > > > eth1.100 is a limb of eth1 > > > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > > > > > > > These seem to be my current favorites: > > > > > > leg/trunk/head > > > > > > limb/trunk/limb > > > > > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > > > > > > > > > For example: > > > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > > > * The br0 is `controller` of eth1 > > > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > > > * The eth1 is `subordinate` of bond0 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > * The base interface of eth1.100 is eth1 > > > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > > > better ideas. > > > > > > > > > > > > > > Thank you very much! > > > > > > > > > > > > Thank you for moving this forward! > > > > > > > > > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Till Maas > > > > > > He/His/Him > > > > > > Associate Manager, Software Engineering > > > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > > > > > Thomas Savage > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Till Maas > > > > He/His/Him > > > > Associate Manager, Software Engineering > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role > > > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, > > > > Thomas Savage > > > > >

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

---

nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Hi,

Am Mi., 2. Sept. 2020 um 12:56 Uhr schrieb Edward Haas edwardh@redhat.com:

On Wed, Sep 2, 2020 at 12:42 PM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 31. Aug. 2020 um 15:40 Uhr schrieb Edward Haas edwardh@redhat.com:

...

On Mon, Aug 31, 2020 at 2:40 PM Till Maas till@redhat.com wrote:

...

Hi,

Am Mo., 31. Aug. 2020 um 12:55 Uhr schrieb Edward Haas edwardh@redhat.com:

...

Hi,

This issue has been referenced by the Kernel community here. That ref also includes other references from several organizations.

My main concern here is that we will diverge from the telco terms which is the source of the current naming using the API. I have not managed to see work on this from IEEE or IETF (e.g. RFC/s proposals). It took centuries for the current technical terms to get stabilized and become a common language for engineers to communicate.

There is this draft: https://tools.ietf.org/id/draft-knodel-terminology-02.html Not sure how much people are still working on it, seems that the oldest version is from 2018.

Thanks. Unfortunately I see not decision made and no specific changes that will sync all to the same naming.

...

...

What I do not prefer to have is a unique Nmstate naming convention which will differ from other telco solutions. If we are talking about internal non-API usage, then anything may work and is easily changeable. But when we look at the API level this may be a serious issue which merits a larger design effort and not just a simple voting.

Since we are talking about only two words, I believe it is reasonable for anyone to learn that different words are used in other contexts. Since we are talking about preparations for nmstate 1.0.0, the inclusive terms need to be chosen sooner than later to ensure that it can be properly communicated and we can avoid this change after 1.0.0.

My claim here is that if we do this prematurely we lose consistency and standardization. If there is no standardization yet, at least some that the big players have agreed on, we should not enforce namings which may surprise our users.

In my opinion, Nmstate is free to choose inclusion over standardization. This does not mean that Nmstate is enforcing this for anyone.

The way I see Nmstate, it is all about the API. Everything else is implementation details.

It seems that API means for you the identifiers used in the schema. According to the nmstate web page and the presentation we did together, those are not the most important part but rather an implementation detail.

To cite the webpage:

---8<--- We are NMState! A declarative network manager API for hosts.

What is it? NMState is a library with an accompanying command line tool that manages host networking settings in a declarative manner. The networking state is described by a pre-defined schema. Reporting of current state and changes to it (desired state) both conform to the schema. ---8<---

It does not state using certain terminology as a primary goal. Also, in our presentation we presented:

- complete state - configuration and reporting - declarative

as key design decisions before mentioning that it is _inspired_ by the IETF Network Modeling Working Group. Also, I would consider the atomic changes, verification and extensibility also more important than the actual terms. In the past, you were interested in adding a NETCONF/YANG compatible layer on top of Nmstate which also highlights that the terms can easily exchanged by anyone who is interested while the other features are harder to replicate and provide the specific value of Nmstate.

As an API layer, its first priority is to be inclusive to other solutions that need networking. That means it better be more sensitive to standardization over humanity's mood and trends.

Please read https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating... Being inclusive towards other human beings is something different than just a mood or trend. To cite:

"If any person or groups of people feel unwelcome because of the language being used in a community, code or documentation, then the words should change."

I am fine with inner changes, I am less comfortable with API changes that will be diverse from other communities' naming (I am not talking about kernel or NM, but upper level management and telco API/s). It is already obvious that every project now will go and choose their own naming internally, but it should be very hard to do it on a public API. If each project will behave like this on public API, we will end up with a mess in general.

While I agree that a common terminilogy would be great, I disagree that using "child" in nmstate but "member" for Cisco switches (see https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html) creates such a big problem. Also, as software evolves, Nmstate can still adapt other inclusive terminilogy in the future.

If the community is seeking real inclusion naming, it better start with the IETF, IEEE and the like, not with little projects that their first priority is to integrate well with all other projects.

I don't agree. Failure of those organizations does not mean that other projects need to fail on being inclusive as well.

...

...

In general, we could introduce another inclusive naming without breaking the existing and control it through configuration. The same can be done in the future when something is agreed in the telco community. The configuration just needs to control the reporting, the setting can accept all options.

Since we have constants for everything, users who prefer offensive over inclusive language can probably adjust this easily on their side IMHO. This seems trivial enough that it does not need a config in Nmstate.

Some see this change as offensive, breaking engineering standards that took decades to stabilize.

I used the wrong word, the actual opposite is exclusive. Nevertheless, being offended by something not following a standard seems to be a really far stretch. This does not target a person.

I am good with not offending anyone, keeping backward compatibility and allowing users to choose their preference and Nmstate ready for future naming changes per the

Users can easily choose their preference by translating Nmstate's terms into their own terminology. This does not require Nmstate to contribute to exclusive behavior.

standardization that comes out of this period.

Thanks Till

...

Thanks Till

...

Will that provide a reasonable solution for this goal?

...

Thanks Till

...

Thanks, Edy.

On Mon, Aug 31, 2020 at 1:33 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

Thanks, Fernando.

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote: > > Another idea for the naming. > > If we consider something like: > > bond0: > - eth0 > - eth1 > - eth2 > - eth3 > > bond0.vlan1 > bond0.vlan2 > > etc, > > - What about calling the physical interfaces "eth0-3" "members" of bond0? > - What about calling "vlan1" "vlan2" are a child of bond0? > > > _W > > > > On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote: >> >> Hi, >> >> Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera >> ferferna@redhat.com: >> >> > Looking on the thread it seems we agree on two points: >> > >> > * We should use a generic word for codebase and for API VLAN/VXLAN >> > will user base/parent, as we are already doing. >> > >> > * Short words are good so controller/subordinate is too long and >> > interface/subinterface are too generic. >> >> my proposal should have been top and sub as the identifiers but I it >> would be spoken as top interface / sub interface. >> >> >> > >> > IMO, we should follow the kernel terms and we shouldn't create new >> > terms because it would be hard to understand for maintainers. >> > https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms... >> > >> > I propose to use: >> > >> > "base/worker" or "main/worker". >> >> This would also lead to base interface and worker interface. >> >> base and worker are not mentioned in the zdnet article. So how about >> "main" and "sub" (short for subordinate). >> >> Can we maybe check at least with someone else involved in the upstream >> kernel to get their opinion if Jarod is not available? >> >> Thanks >> Till >> >> > >> > If there is no complaint on this I will work on this by next week, so >> > please, share your thoughts. :-) >> > >> > Thanks! >> > Fernando. >> > >> > On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera >> > ferferna@redhat.com wrote: >> > > >> > > Sorry, I meant "base/leg". >> > > >> > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera >> > > ferferna@redhat.com wrote: >> > > > >> > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: >> > > > > >> > > > > Hi, >> > > > > >> > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera >> > > > > ferferna@redhat.com: >> > > > > > >> > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: >> > > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: >> > > > > > > > >> > > > > > > > Hi, >> > > > > > > > >> > > > > > > > I would like to suggest we deprecate our use of `master/slave` in >> > > > > > > > nmstate project. >> > > > > > > > >> > > > > > > > And switching to these terminologies for interface relationship in >> > > > > > > > the coming new release of nmstate-0.4.0: >> > > > > > > > >> > > > > > > > * For bond/team/bridge: >> > > > > > > > * controller/subordinate >> > > > > > > > # For bridge, we can also use controller/port. >> > > > > > > >> > > > > > > having shorter words would be nice, maybe >> > > > > > > >> > > > > > > trunk/leg >> > > > > > > base/leg >> > > > > > > >> > > > > > > base/dell >> > > > > > > mesa/dell >> > > > > > > base/vale >> > > > > > > >> > > > > > > bulk/part >> > > > > > > >> > > > > > > > >> > > > > > > > * For VLAN/VxLAN: >> > > > > > > > * parent/child >> > > > > > > > * base/child >> > > > > > > > # Current API using `base-iface`, no need to change >> > > > > > > >> > > > > > > Some other suggestions: >> > > > > > > base/apex >> > > > > > > mesa/apex >> > > > > > > >> > > > > > > base/head >> > > > > > > trunk/head >> > > > > > >> > > > > > Those are a little bit confusing for me. I expect both "base" and >> > > > > > "head" would replace "master". >> > > > > >> > > > > Interesting. This might be because I did not think about the old >> > > > > analogy where one interface has power over the other but more like how >> > > > > they are arranged. >> > > > > >> > > > > Bond interfaces are built on top of other interfaces, making the other >> > > > > interfaces something at the bottom (like legs) and the bond interface >> > > > > the trunk or base. Since VLAN interfaces are also built on top of >> > > > > other interfaces, even on bond interfaces, this makes them another top >> > > > > layer which is the head. But since there could be multiple VLAns, arms >> > > > > might make more sense and then both arms and legs are limbs. >> > > > > >> > > > > > I've been thinking on this and it would be good to use only one option >> > > > > > for codebase, i.e using the same terms for all kind of interfaces. For >> > > > > > the exposed API, I would not change VLAN/VXLAN as we are already using >> > > > > > base/child terms. For other interfaces I noticed that we are mixing up >> > > > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, >> > > > > > the most generic are "controller/subordinate". >> > > > > > >> > > > > > If we agree on the generic word, I would use them for the whole codebase. >> > > > > > >> > > > > > What do you think? Thanks! >> > > > > >> > > > > I am not sure if the power structure is the best analogy, here. Does a >> > > > > bond/bridge interface really control its subordinate interfaces? Maybe >> > > > > it also does not matter that much, given that at some point the words >> > > > > will be defined by usage. However, using long words might not stick >> > > > > since people are lazy. A shorter alternative might be top >> > > > > interface/sub interface. >> > > > > >> > > > >> > > > Yes, that is true. It would be nice to use a shorter word.. maybe >> > > > "parent/child"? As parents have power over their childs.. Not sure. >> > > > About interface/subinterface, I find them very lazy, "interface" term >> > > > is all over the codebase so it could be very confusing for us, IMO. >> > > > >> > > > I also like "base/lag"- >> > > > >> > > > Thanks! >> > > > >> > > > > Thanks >> > > > > Till >> > > > > >> > > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > The trunk interface of eth1 is bond0 >> > > > > > > eth1 is a leg of the bridge br0 >> > > > > > > eth1 is a leg of an base interface >> > > > > > > eth1 is a dell interface of br0 (probably not so nice because of the >> > > > > > > confusion with the manufacturer) >> > > > > > > eth1 is a vale interface of br0 >> > > > > > > eth1 is a limb of br0 >> > > > > > > eth1 is a leg of br0 >> > > > > > > br0 is the trunk for eth1 >> > > > > > > >> > > > > > > >> > > > > > > eth1 is a part interface of the br0 bulk interface >> > > > > > > >> > > > > > > >> > > > > > > the base of VLAN eth1.100 is eth1 >> > > > > > > eth1.100 is an apex interface of eth1 >> > > > > > > eth1.100 is a head of eth1 >> > > > > > > eth1 is the trunk interface for eth1.100. >> > > > > > > eth1 is the base interface for eth1.100. >> > > > > > > eth1 is the trunk for eth1.100 >> > > > > > > eth1.100 is a limb of eth1 >> > > > > > > eth1.100 is an arm of eth1 >> > > > > > > >> > > > > > > >> > > > > > > These seem to be my current favorites: >> > > > > > > leg/trunk/head >> > > > > > > limb/trunk/limb >> > > > > > > >> > > > > > > Limb could be used both for the interfaces included in a bridge or a >> > > > > > > bond. Not sure, if they need to have different identifiers. >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > For example: >> > > > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond >> > > > > > > > * The br0 is `controller` of eth1 >> > > > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 >> > > > > > > > * The eth1 is `subordinate` of bond0 >> > > > > > > > * The VLAN eth1.100 is child of eth1 >> > > > > > > > * The base interface of eth1.100 is eth1 >> > > > > > > > * The parent of VLAN eth1.100 is eth1 >> > > > > > > > * The VLAN eth1.100 is child of eth1 >> > > > > > > > >> > > > > > > > I am not English native speaker, please kindly help on this if you have >> > > > > > > > better ideas. >> > > > > > > > >> > > > > > > > Thank you very much! >> > > > > > > >> > > > > > > Thank you for moving this forward! >> > > > > > > >> > > > > > > Till >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > Till Maas >> > > > > > > He/His/Him >> > > > > > > Associate Manager, Software Engineering >> > > > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role >> > > > > > > >> > > > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> > > > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, >> > > > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, >> > > > > > > Thomas Savage >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Till Maas >> > > > > He/His/Him >> > > > > Associate Manager, Software Engineering >> > > > > NetworkManager, Nmstate, Ansible RHEL Networking System Role >> > > > > >> > > > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> > > > > Commercial register: Amtsgericht Muenchen, HRB 153243, >> > > > > Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, >> > > > > Thomas Savage >> > > > > >> > >> >> >> -- >> Till Maas >> He/His/Him >> Associate Manager, Software Engineering >> NetworkManager, Nmstate, Ansible RHEL Networking System Role >> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, >> Thomas Savage >> _______________________________________________ >> nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org >> To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste... _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

-- Till Maas He/His/Him Associate Manager, Software Engineering NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

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.

Thanks, Fernando.

On Tue, Sep 1, 2020 at 4:28 PM Beniamino Galvani bgalvani@redhat.com wrote:

On Mon, Aug 31, 2020 at 12:32:33PM +0200, Fernando Fernandez Mancera wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

In NetworkManager the parent/child terminology is used for interfaces like VLANs, IP tunnels, PPPoE where an interface is stacked upon another without relation to other 'siblings'.

...

• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

I like (in this order) {'base', 'main'} for the master and {'port', 'member'} for slaves.

Beniamino

...

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

...

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers. https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

I propose to use:

"base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

...

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote: > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > Hi, > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > ferferna@redhat.com: > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > Hi, > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > nmstate project. > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > * For bond/team/bridge: > > > > > * controller/subordinate > > > > > # For bridge, we can also use controller/port. > > > > > > > > having shorter words would be nice, maybe > > > > > > > > trunk/leg > > > > base/leg > > > > > > > > base/dell > > > > mesa/dell > > > > base/vale > > > > > > > > bulk/part > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > * parent/child > > > > > * base/child > > > > > # Current API using `base-iface`, no need to change > > > > > > > > Some other suggestions: > > > > base/apex > > > > mesa/apex > > > > > > > > base/head > > > > trunk/head > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > "head" would replace "master". > > > > Interesting. This might be because I did not think about the old > > analogy where one interface has power over the other but more like how > > they are arranged. > > > > Bond interfaces are built on top of other interfaces, making the other > > interfaces something at the bottom (like legs) and the bond interface > > the trunk or base. Since VLAN interfaces are also built on top of > > other interfaces, even on bond interfaces, this makes them another top > > layer which is the head. But since there could be multiple VLAns, arms > > might make more sense and then both arms and legs are limbs. > > > > > I've been thinking on this and it would be good to use only one option > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > base/child terms. For other interfaces I noticed that we are mixing up > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > the most generic are "controller/subordinate". > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > What do you think? Thanks! > > > > I am not sure if the power structure is the best analogy, here. Does a > > bond/bridge interface really control its subordinate interfaces? Maybe > > it also does not matter that much, given that at some point the words > > will be defined by usage. However, using long words might not stick > > since people are lazy. A shorter alternative might be top > > interface/sub interface. > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > "parent/child"? As parents have power over their childs.. Not sure. > About interface/subinterface, I find them very lazy, "interface" term > is all over the codebase so it could be very confusing for us, IMO. > > I also like "base/lag"- > > Thanks! > > > Thanks > > Till > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > eth1 is a leg of the bridge br0 > > > > eth1 is a leg of an base interface > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > confusion with the manufacturer) > > > > eth1 is a vale interface of br0 > > > > eth1 is a limb of br0 > > > > eth1 is a leg of br0 > > > > br0 is the trunk for eth1 > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > eth1.100 is an apex interface of eth1 > > > > eth1.100 is a head of eth1 > > > > eth1 is the trunk interface for eth1.100. > > > > eth1 is the base interface for eth1.100. > > > > eth1 is the trunk for eth1.100 > > > > eth1.100 is a limb of eth1 > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > These seem to be my current favorites: > > > > leg/trunk/head > > > > limb/trunk/limb > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > For example: > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > * The br0 is `controller` of eth1 > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > * The eth1 is `subordinate` of bond0 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > * The base interface of eth1.100 is eth1 > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > better ideas. > > > > > > > > > > Thank you very much! > > > > > > > > Thank you for moving this forward! > > > > > > > > Till

Thank you very much for your suggestions Jarod. We will take them into account.

Thanks! Fernando.

On Tue, Sep 1, 2020 at 10:06 PM Jarod Wilson jarod@redhat.com wrote:

On Tue, Sep 1, 2020 at 3:43 PM Fernando Fernandez Mancera ferferna@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.

Note: there's also an open bugzilla for this issue, specific to the bonding driver.

...

On Tue, Sep 1, 2020 at 4:28 PM Beniamino Galvani bgalvani@redhat.com wrote:

...

On Mon, Aug 31, 2020 at 12:32:33PM +0200, Fernando Fernandez Mancera wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

In NetworkManager the parent/child terminology is used for interfaces like VLANs, IP tunnels, PPPoE where an interface is stacked upon another without relation to other 'siblings'.

...

• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

I like (in this order) {'base', 'main'} for the master and {'port', 'member'} for slaves.

Beniamino

...

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

> Looking on the thread it seems we agree on two points: > > * We should use a generic word for codebase and for API VLAN/VXLAN > will user base/parent, as we are already doing. > > * Short words are good so controller/subordinate is too long and > interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

> > IMO, we should follow the kernel terms and we shouldn't create new > terms because it would be hard to understand for maintainers. > https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms... > > I propose to use: > > "base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

> > If there is no complaint on this I will work on this by next week, so > please, share your thoughts. :-) > > Thanks! > Fernando. > > On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera > ferferna@redhat.com wrote: > > > > Sorry, I meant "base/leg". > > > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera > > ferferna@redhat.com wrote: > > > > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > > > ferferna@redhat.com: > > > > > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > > > nmstate project. > > > > > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > > > > > * For bond/team/bridge: > > > > > > > * controller/subordinate > > > > > > > # For bridge, we can also use controller/port. > > > > > > > > > > > > having shorter words would be nice, maybe > > > > > > > > > > > > trunk/leg > > > > > > base/leg > > > > > > > > > > > > base/dell > > > > > > mesa/dell > > > > > > base/vale > > > > > > > > > > > > bulk/part > > > > > > > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > > > * parent/child > > > > > > > * base/child > > > > > > > # Current API using `base-iface`, no need to change > > > > > > > > > > > > Some other suggestions: > > > > > > base/apex > > > > > > mesa/apex > > > > > > > > > > > > base/head > > > > > > trunk/head > > > > > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > > > "head" would replace "master". > > > > > > > > Interesting. This might be because I did not think about the old > > > > analogy where one interface has power over the other but more like how > > > > they are arranged. > > > > > > > > Bond interfaces are built on top of other interfaces, making the other > > > > interfaces something at the bottom (like legs) and the bond interface > > > > the trunk or base. Since VLAN interfaces are also built on top of > > > > other interfaces, even on bond interfaces, this makes them another top > > > > layer which is the head. But since there could be multiple VLAns, arms > > > > might make more sense and then both arms and legs are limbs. > > > > > > > > > I've been thinking on this and it would be good to use only one option > > > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > > > base/child terms. For other interfaces I noticed that we are mixing up > > > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > > > the most generic are "controller/subordinate". > > > > > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > > > > > What do you think? Thanks! > > > > > > > > I am not sure if the power structure is the best analogy, here. Does a > > > > bond/bridge interface really control its subordinate interfaces? Maybe > > > > it also does not matter that much, given that at some point the words > > > > will be defined by usage. However, using long words might not stick > > > > since people are lazy. A shorter alternative might be top > > > > interface/sub interface. > > > > > > > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > > > "parent/child"? As parents have power over their childs.. Not sure. > > > About interface/subinterface, I find them very lazy, "interface" term > > > is all over the codebase so it could be very confusing for us, IMO. > > > > > > I also like "base/lag"- > > > > > > Thanks! > > > > > > > Thanks > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > > > eth1 is a leg of the bridge br0 > > > > > > eth1 is a leg of an base interface > > > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > > > confusion with the manufacturer) > > > > > > eth1 is a vale interface of br0 > > > > > > eth1 is a limb of br0 > > > > > > eth1 is a leg of br0 > > > > > > br0 is the trunk for eth1 > > > > > > > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > > > eth1.100 is an apex interface of eth1 > > > > > > eth1.100 is a head of eth1 > > > > > > eth1 is the trunk interface for eth1.100. > > > > > > eth1 is the base interface for eth1.100. > > > > > > eth1 is the trunk for eth1.100 > > > > > > eth1.100 is a limb of eth1 > > > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > > > > > > > These seem to be my current favorites: > > > > > > leg/trunk/head > > > > > > limb/trunk/limb > > > > > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > > > > > > > > > For example: > > > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > > > * The br0 is `controller` of eth1 > > > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > > > * The eth1 is `subordinate` of bond0 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > * The base interface of eth1.100 is eth1 > > > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > > > better ideas. > > > > > > > > > > > > > > Thank you very much! > > > > > > > > > > > > Thank you for moving this forward! > > > > > >

-- Jarod Wilson jarod@redhat.com _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

Hi,

Am Di., 1. Sept. 2020 um 22:04 Uhr schrieb Jarod Wilson jarod@redhat.com:

On Tue, Sep 1, 2020 at 3:43 PM Fernando Fernandez Mancera ferferna@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. :-)

Note: there's also an open bugzilla for this issue, specific to the bonding driver.

what's the ID?

Thanks Till

...

On Tue, Sep 1, 2020 at 4:28 PM Beniamino Galvani bgalvani@redhat.com wrote:

...

On Mon, Aug 31, 2020 at 12:32:33PM +0200, Fernando Fernandez Mancera wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

In NetworkManager the parent/child terminology is used for interfaces like VLANs, IP tunnels, PPPoE where an interface is stacked upon another without relation to other 'siblings'.

...

• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

I like (in this order) {'base', 'main'} for the master and {'port', 'member'} for slaves.

Beniamino

...

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

> Looking on the thread it seems we agree on two points: > > * We should use a generic word for codebase and for API VLAN/VXLAN > will user base/parent, as we are already doing. > > * Short words are good so controller/subordinate is too long and > interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

> > IMO, we should follow the kernel terms and we shouldn't create new > terms because it would be hard to understand for maintainers. > https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms... > > I propose to use: > > "base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

> > If there is no complaint on this I will work on this by next week, so > please, share your thoughts. :-) > > Thanks! > Fernando. > > On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera > ferferna@redhat.com wrote: > > > > Sorry, I meant "base/leg". > > > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera > > ferferna@redhat.com wrote: > > > > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > > > ferferna@redhat.com: > > > > > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > > > nmstate project. > > > > > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > > > > > * For bond/team/bridge: > > > > > > > * controller/subordinate > > > > > > > # For bridge, we can also use controller/port. > > > > > > > > > > > > having shorter words would be nice, maybe > > > > > > > > > > > > trunk/leg > > > > > > base/leg > > > > > > > > > > > > base/dell > > > > > > mesa/dell > > > > > > base/vale > > > > > > > > > > > > bulk/part > > > > > > > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > > > * parent/child > > > > > > > * base/child > > > > > > > # Current API using `base-iface`, no need to change > > > > > > > > > > > > Some other suggestions: > > > > > > base/apex > > > > > > mesa/apex > > > > > > > > > > > > base/head > > > > > > trunk/head > > > > > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > > > "head" would replace "master". > > > > > > > > Interesting. This might be because I did not think about the old > > > > analogy where one interface has power over the other but more like how > > > > they are arranged. > > > > > > > > Bond interfaces are built on top of other interfaces, making the other > > > > interfaces something at the bottom (like legs) and the bond interface > > > > the trunk or base. Since VLAN interfaces are also built on top of > > > > other interfaces, even on bond interfaces, this makes them another top > > > > layer which is the head. But since there could be multiple VLAns, arms > > > > might make more sense and then both arms and legs are limbs. > > > > > > > > > I've been thinking on this and it would be good to use only one option > > > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > > > base/child terms. For other interfaces I noticed that we are mixing up > > > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > > > the most generic are "controller/subordinate". > > > > > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > > > > > What do you think? Thanks! > > > > > > > > I am not sure if the power structure is the best analogy, here. Does a > > > > bond/bridge interface really control its subordinate interfaces? Maybe > > > > it also does not matter that much, given that at some point the words > > > > will be defined by usage. However, using long words might not stick > > > > since people are lazy. A shorter alternative might be top > > > > interface/sub interface. > > > > > > > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > > > "parent/child"? As parents have power over their childs.. Not sure. > > > About interface/subinterface, I find them very lazy, "interface" term > > > is all over the codebase so it could be very confusing for us, IMO. > > > > > > I also like "base/lag"- > > > > > > Thanks! > > > > > > > Thanks > > > > Till > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > > > eth1 is a leg of the bridge br0 > > > > > > eth1 is a leg of an base interface > > > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > > > confusion with the manufacturer) > > > > > > eth1 is a vale interface of br0 > > > > > > eth1 is a limb of br0 > > > > > > eth1 is a leg of br0 > > > > > > br0 is the trunk for eth1 > > > > > > > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > > > eth1.100 is an apex interface of eth1 > > > > > > eth1.100 is a head of eth1 > > > > > > eth1 is the trunk interface for eth1.100. > > > > > > eth1 is the base interface for eth1.100. > > > > > > eth1 is the trunk for eth1.100 > > > > > > eth1.100 is a limb of eth1 > > > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > > > > > > > These seem to be my current favorites: > > > > > > leg/trunk/head > > > > > > limb/trunk/limb > > > > > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > > > > > > > > > For example: > > > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > > > * The br0 is `controller` of eth1 > > > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > > > * The eth1 is `subordinate` of bond0 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > * The base interface of eth1.100 is eth1 > > > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > > > better ideas. > > > > > > > > > > > > > > Thank you very much! > > > > > > > > > > > > Thank you for moving this forward! > > > > > >

-- Jarod Wilson jarod@redhat.com _______________________________________________ nmstate-devel mailing list -- nmstate-devel@lists.fedorahosted.org To unsubscribe send an email to nmstate-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/nmstate-devel@lists.fedorahoste...

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@redhat.com wrote:

On Wed, Sep 2, 2020 at 5:22 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Di., 1. Sept. 2020 um 22:04 Uhr schrieb Jarod Wilson jarod@redhat.com:

...

On Tue, Sep 1, 2020 at 3:43 PM Fernando Fernandez Mancera ferferna@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@redhat.com

Why would that be that bad? In this case the word will only be used on internal code and nmstate API. If in the future there is an agreement on the kernel we are open to adopt it. I hope this is not a problem for the kernel.

Thanks Jarod! Fernando.

On Thu, Sep 3, 2020 at 10:01 PM Jarod Wilson jarod@redhat.com wrote:

On Thu, Sep 3, 2020 at 3:51 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

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.

Well. That was an unfortunate decision from a bonding driver point of view. As I thought I'd previously mentioned, 'port' is already used quite extensively in the bonding driver's 802.3ad/lacp code.

-- Jarod Wilson jarod@redhat.com

Hi,

Am Fr., 4. Sept. 2020 um 15:47 Uhr schrieb Jarod Wilson jarod@redhat.com:

On Fri, Sep 4, 2020 at 3:20 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Why would that be that bad? In this case the word will only be used on internal code and nmstate API. If in the future there is an agreement on the kernel we are open to adopt it. I hope this is not a problem for the kernel.

I was under the impression we were trying to select terms that could easily be used everywhere. Part of me would like to use port in the

Yes, that would be the holy grail. This is why we are still open for further changes in the future if better terms become widely accepted. Also, for NetworkManager it is more complicated, so would still welcome an agreement that would help to improve NetworkManager, too.

bonding driver, which would actually mirror the team driver, but doing so would cause even more renaming churn in the bonding driver, due to it already being used in other contexts:

$ git grep -c port drivers/net/bonding/ drivers/net/bonding/bond_3ad.c:771 drivers/net/bonding/bond_alb.c:2 drivers/net/bonding/bond_main.c:45 drivers/net/bonding/bond_netlink.c:9 drivers/net/bonding/bond_options.c:10 drivers/net/bonding/bond_procfs.c:28 drivers/net/bonding/bond_sysfs.c:11 drivers/net/bonding/bond_sysfs_slave.c:15

It could be done, but... it would be very messy. Another combo I like,

Just wondering, would it be possible to use port on the public part, which might be just the output of /proc/net/bonding/$interface - so

Primary Port: Currently Active Port: Port Interface: Port queue ID:

but hadn't looked into until now: master -> aggregate and slave -> link, since bonding is explicitly described as being a link aggregation driver. There's use of 'link' in the bonding driver already, but it looks fairly simple to adjust (it's used for link state tracking, up/down/etc)...

sounds like good terms, too. Just wondering, who needs to be convinced on the kernel side to move this forward?

Thanks Till

...

On Thu, Sep 3, 2020 at 10:01 PM Jarod Wilson jarod@redhat.com wrote:

...

On Thu, Sep 3, 2020 at 3:51 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

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.

Well. That was an unfortunate decision from a bonding driver point of view. As I thought I'd previously mentioned, 'port' is already used quite extensively in the bonding driver's 802.3ad/lacp code.

-- Jarod Wilson jarod@redhat.com

-- Jarod Wilson jarod@redhat.com

Hi,

Am Di., 1. Sept. 2020 um 16:28 Uhr schrieb Beniamino Galvani bgalvani@redhat.com:

On Mon, Aug 31, 2020 at 12:32:33PM +0200, Fernando Fernandez Mancera wrote:

...

Hello everyone,

I am asking for ideas and tomorrow I will open a public voting on the mailing list. So, please add your suggestions now. The current ones are:

• main/sub
• main/member
• parent/child
• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

In NetworkManager the parent/child terminology is used for interfaces like VLANs, IP tunnels, PPPoE where an interface is stacked upon another without relation to other 'siblings'.

Would it be a problem to also use parent/child for bond/bridges? Is it necessary to be able to distinguish this?

Thanks Till

...

• base/child
• main/worker
• trunk/leg
• base/leg

Please, feel free to add other terms.

I like (in this order) {'base', 'main'} for the master and {'port', 'member'} for slaves.

Beniamino

...

On Thu, Aug 27, 2020 at 2:31 PM William Caban Babilonia william.caban@redhat.com wrote:

...

Another idea for the naming.

If we consider something like:

bond0:

• eth0
• eth1
• eth2
• eth3

bond0.vlan1 bond0.vlan2

etc,

• What about calling the physical interfaces "eth0-3" "members" of bond0?
• What about calling "vlan1" "vlan2" are a child of bond0?

_W

On Thu, Aug 27, 2020 at 6:33 AM Till Maas till@redhat.com wrote:

...

Hi,

Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera ferferna@redhat.com:

...

Looking on the thread it seems we agree on two points:

• We should use a generic word for codebase and for API VLAN/VXLAN

will user base/parent, as we are already doing.

• Short words are good so controller/subordinate is too long and

interface/subinterface are too generic.

my proposal should have been top and sub as the identifiers but I it would be spoken as top interface / sub interface.

...

IMO, we should follow the kernel terms and we shouldn't create new terms because it would be hard to understand for maintainers. https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms...

I propose to use:

"base/worker" or "main/worker".

This would also lead to base interface and worker interface.

base and worker are not mentioned in the zdnet article. So how about "main" and "sub" (short for subordinate).

Can we maybe check at least with someone else involved in the upstream kernel to get their opinion if Jarod is not available?

Thanks Till

...

If there is no complaint on this I will work on this by next week, so please, share your thoughts. :-)

Thanks! Fernando.

On Mon, Aug 24, 2020 at 11:01 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:

...

Sorry, I meant "base/leg".

On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera ferferna@redhat.com wrote: > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas till@redhat.com wrote: > > > > Hi, > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb Fernando Fernandez Mancera > > ferferna@redhat.com: > > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas till@redhat.com wrote: > > > > > > > > Hi, > > > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr schrieb Gris Ge fge@redhat.com: > > > > > > > > > > Hi, > > > > > > > > > > I would like to suggest we deprecate our use of `master/slave` in > > > > > nmstate project. > > > > > > > > > > And switching to these terminologies for interface relationship in > > > > > the coming new release of nmstate-0.4.0: > > > > > > > > > > * For bond/team/bridge: > > > > > * controller/subordinate > > > > > # For bridge, we can also use controller/port. > > > > > > > > having shorter words would be nice, maybe > > > > > > > > trunk/leg > > > > base/leg > > > > > > > > base/dell > > > > mesa/dell > > > > base/vale > > > > > > > > bulk/part > > > > > > > > > > > > > > * For VLAN/VxLAN: > > > > > * parent/child > > > > > * base/child > > > > > # Current API using `base-iface`, no need to change > > > > > > > > Some other suggestions: > > > > base/apex > > > > mesa/apex > > > > > > > > base/head > > > > trunk/head > > > > > > Those are a little bit confusing for me. I expect both "base" and > > > "head" would replace "master". > > > > Interesting. This might be because I did not think about the old > > analogy where one interface has power over the other but more like how > > they are arranged. > > > > Bond interfaces are built on top of other interfaces, making the other > > interfaces something at the bottom (like legs) and the bond interface > > the trunk or base. Since VLAN interfaces are also built on top of > > other interfaces, even on bond interfaces, this makes them another top > > layer which is the head. But since there could be multiple VLAns, arms > > might make more sense and then both arms and legs are limbs. > > > > > I've been thinking on this and it would be good to use only one option > > > for codebase, i.e using the same terms for all kind of interfaces. For > > > the exposed API, I would not change VLAN/VXLAN as we are already using > > > base/child terms. For other interfaces I noticed that we are mixing up > > > "slaves" and "ports", I suggest to unify it into a generic one. IMO, > > > the most generic are "controller/subordinate". > > > > > > If we agree on the generic word, I would use them for the whole codebase. > > > > > > What do you think? Thanks! > > > > I am not sure if the power structure is the best analogy, here. Does a > > bond/bridge interface really control its subordinate interfaces? Maybe > > it also does not matter that much, given that at some point the words > > will be defined by usage. However, using long words might not stick > > since people are lazy. A shorter alternative might be top > > interface/sub interface. > > > > Yes, that is true. It would be nice to use a shorter word.. maybe > "parent/child"? As parents have power over their childs.. Not sure. > About interface/subinterface, I find them very lazy, "interface" term > is all over the codebase so it could be very confusing for us, IMO. > > I also like "base/lag"- > > Thanks! > > > Thanks > > Till > > > > > > > > > > > > > > > > > > > The trunk interface of eth1 is bond0 > > > > eth1 is a leg of the bridge br0 > > > > eth1 is a leg of an base interface > > > > eth1 is a dell interface of br0 (probably not so nice because of the > > > > confusion with the manufacturer) > > > > eth1 is a vale interface of br0 > > > > eth1 is a limb of br0 > > > > eth1 is a leg of br0 > > > > br0 is the trunk for eth1 > > > > > > > > > > > > eth1 is a part interface of the br0 bulk interface > > > > > > > > > > > > the base of VLAN eth1.100 is eth1 > > > > eth1.100 is an apex interface of eth1 > > > > eth1.100 is a head of eth1 > > > > eth1 is the trunk interface for eth1.100. > > > > eth1 is the base interface for eth1.100. > > > > eth1 is the trunk for eth1.100 > > > > eth1.100 is a limb of eth1 > > > > eth1.100 is an arm of eth1 > > > > > > > > > > > > These seem to be my current favorites: > > > > leg/trunk/head > > > > limb/trunk/limb > > > > > > > > Limb could be used both for the interfaces included in a bridge or a > > > > bond. Not sure, if they need to have different identifiers. > > > > > > > > > > > > > > > > > > For example: > > > > > * The `controller` of eth1 is bond0 and `controller_type` is bond > > > > > * The br0 is `controller` of eth1 > > > > > * The eth1 is `port` of bridge br0 or `subordinate` of bridge br0 > > > > > * The eth1 is `subordinate` of bond0 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > * The base interface of eth1.100 is eth1 > > > > > * The parent of VLAN eth1.100 is eth1 > > > > > * The VLAN eth1.100 is child of eth1 > > > > > > > > > > I am not English native speaker, please kindly help on this if you have > > > > > better ideas. > > > > > > > > > > Thank you very much! > > > > > > > > Thank you for moving this forward! > > > > > > > > Till