On Wed, Sep 02, 2020 at 11:19:27AM +0200, Till Maas wrote:
Hi,
Am Di., 1. Sept. 2020 um 16:28 Uhr schrieb Beniamino Galvani
<bgalvani(a)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?
For NetworkManager, it will be a bit confusing. There is API to set
the 'vlan.parent', i.e. the interface that the VLAN is stacked on; the
master is specified by 'connection.master'.
If we change (*) 'connection.master' to 'connection.parent' now we
have two similar properties: 'connection.parent' and 'vlan.parent'.
(*) API can't be just changed, we have to keep the old property,
deprecate it and add the new one.
Is it necessary to be able to distinguish this?
Yes, I think they are 2 different concepts. A vlan needs a parent
(e.g. an ethernet), but can also be under a bridge/bond/team. So,
having 2 parents becomes ambiguous: it's not clear if it's a VLAN on
top of interface1 and member of interface2 or the other way around.
Beniamino
> > - 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(a)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(a)redhat.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Am Do., 27. Aug. 2020 um 11:49 Uhr schrieb Fernando Fernandez Mancera
> > >> <ferferna(a)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-te...
> > >> >
> > >> > 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(a)redhat.com> wrote:
> > >> > >
> > >> > > Sorry, I meant "base/leg".
> > >> > >
> > >> > > On Mon, Aug 24, 2020 at 10:59 AM Fernando Fernandez Mancera
> > >> > > <ferferna(a)redhat.com> wrote:
> > >> > > >
> > >> > > > On Mon, Aug 24, 2020 at 10:35 AM Till Maas
<till(a)redhat.com> wrote:
> > >> > > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > Am Mo., 24. Aug. 2020 um 10:14 Uhr schrieb
Fernando Fernandez Mancera
> > >> > > > > <ferferna(a)redhat.com>:
> > >> > > > > >
> > >> > > > > > On Mon, Aug 24, 2020 at 9:58 AM Till Maas
<till(a)redhat.com> wrote:
> > >> > > > > > >
> > >> > > > > > > Hi,
> > >> > > > > > >
> > >> > > > > > > Am Do., 13. Aug. 2020 um 17:06 Uhr
schrieb Gris Ge <fge(a)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,
https://de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill