Hi,
Am Mi., 2. Sept. 2020 um 12:56 Uhr schrieb Edward Haas <edwardh(a)redhat.com>:
On Wed, Sep 2, 2020 at 12:42 PM Till Maas <till(a)redhat.com> wrote:
>
> Hi,
>
> Am Mo., 31. Aug. 2020 um 15:40 Uhr schrieb Edward Haas <edwardh(a)redhat.com>:
> >
> >
> >
> > 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 my opinion, Nmstate is free to choose inclusion over
> standardization. This does not mean that Nmstate is enforcing this for
> anyone.
The way I see Nmstate, it is all about the API. Everything else is
implementation details.
It seems that API means for you the identifiers used in the schema.
According to the nmstate web page and the presentation we did
together, those are not the most important part but rather an
implementation detail.
To cite the webpage:
---8<---
We are NMState!
A declarative network manager API for hosts.
What is it?
NMState is a library with an accompanying command line tool that
manages host networking settings in a declarative manner. The
networking state is described by a pre-defined schema. Reporting of
current state and changes to it (desired state) both conform to the
schema.
---8<---
It does not state using certain terminology as a primary goal. Also,
in our presentation we presented:
- complete state
- configuration and reporting
- declarative
as key design decisions before mentioning that it is _inspired_ by the
IETF Network Modeling Working Group. Also, I would consider the atomic
changes, verification and extensibility also more important than the
actual terms. In the past, you were interested in adding a
NETCONF/YANG compatible layer on top of Nmstate which also highlights
that the terms can easily exchanged by anyone who is interested while
the other features are harder to replicate and provide the specific
value of Nmstate.
As an API layer, its first priority is to be inclusive to other
solutions that need networking. That means it
better be more sensitive to standardization over humanity's mood and trends.
Please read
https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicat...
Being inclusive towards other human beings is something different than
just a mood or trend. To cite:
"If any person or groups of people feel unwelcome because of the
language being used in a community, code or documentation, then the
words should change."
I am fine with inner changes, I am less comfortable with API changes
that will be diverse from other
communities' naming (I am not talking about kernel or NM, but upper
level management and telco API/s).
It is already obvious that every project now will go and choose their
own naming internally, but it should be
very hard to do it on a public API. If each project will behave like
this on public API, we will end up with a mess in general.
While I agree that a common terminilogy would be great, I disagree
that using "child" in nmstate but "member" for Cisco switches (see
https://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/gigeth.html)
creates such a big problem. Also, as software evolves, Nmstate can
still adapt other inclusive terminilogy in the future.
If the community is seeking real inclusion naming, it better start
with the IETF, IEEE and the like, not with little projects that
their first priority is to integrate well with all other projects.
I don't agree. Failure of those organizations does not mean that other
projects need to fail on being inclusive as well.
> > 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.
>
> Since we have constants for everything, users who prefer offensive
> over inclusive language can probably adjust this easily on their side
> IMHO. This seems trivial enough that it does not need a config in
> Nmstate.
Some see this change as offensive, breaking engineering standards that
took decades to stabilize.
I used the wrong word, the actual opposite is exclusive. Nevertheless,
being offended by something not following a standard seems to be a
really far stretch. This does not target a person.
I am good with not offending anyone, keeping backward compatibility
and allowing users to choose their
preference and Nmstate ready for future naming changes per the
Users can easily choose their preference by translating Nmstate's
terms into their own terminology. This does not require Nmstate to
contribute to exclusive behavior.
standardization that comes out of this period.
Thanks
Till
>
> Thanks
> Till
>
> > Will that provide a reasonable solution for this goal?
> >
> >>
> >> 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
> >> >> >> > > > > > >
> >> >> >> > > > > > >
> >> >> >> > > > > > >
> >> >> >> > > > > > > --
> >> >> >> > > > > > > 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...
> >>
> >>
> >>
> >> --
> >> 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
> >>
>
>
> --
> 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
>
--
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