On Mon, Aug 31, 2020 at 7:18 PM Fernando Fernandez Mancera <
ferferna(a)redhat.com> wrote:
On Mon, Aug 31, 2020 at 3:40 PM Edward Haas
<edwardh(a)redhat.com> wrote:
>
>
>
> On Mon, Aug 31, 2020 at 2:40 PM Till Maas <till(a)redhat.com> wrote:
>>
>> Hi,
>>
>> Am Mo., 31. Aug. 2020 um 12:55 Uhr schrieb Edward Haas <
edwardh(a)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?
Sure, I have no concerns with internal code, only with the external API.
By the way, do you suggest any words? :-)
From the list, I feel comfortable with parent/child if you are looking for
a generic relationship naming.
In the schema we usually specify the slaves by name, there we could use
"port" or its plural version for both bridges and bonds.
The team interface equivalent [1] to "slave" is "port" and this fits
with
bridges having ports as well.
So in case you have a code snippet that used "slaves" we could use
"ports"
instead. If there is a need to point to its "master", then
either use the specific type name (e.g. bridge, bond, team) or if a generic
usage is needed, "parent" sounds good to me.
1.
https://github.com/jpirko/libteam/wiki/Infrastructure-Specification#team-...
Thanks!
Fernando.
>>
>> Thanks
>> Till
>>
>> >
>> > 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