.
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(a)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(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...
_______________________________________________
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...