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.
I propose to use:
"base/worker" or "main/worker".
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,
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
> >