Hi,
Am Mo., 31. Aug. 2020 um 12:32 Uhr schrieb Fernando Fernandez Mancera
<ferferna(a)redhat.com>:
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(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,
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(a)lists.fedorahosted.org
>> To unsubscribe send an email to nmstate-devel-leave(a)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.fedoraho...
--
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role
Red Hat GmbH,
, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill