Re: [nmstate] [RFC] ip route partial editing vs whole-state editing


Am Mi., 20. März 2019 um 18:13 Uhr schrieb Edward Haas via
networkmanager-list <networkmanager-list gnome org>:

On Wed, Mar 13, 2019 at 3:48 PM Gris Ge via networkmanager-list <networkmanager-list gnome org> wrote:

Hi Guys,

For the IP route editing in nmstate, the parietal editing is

User case A:
    Current routes: via dev eth1
    Desired routes:         changed next hope to

User case B:
    Current routes: via dev eth1
    Desired routes:         add another route entry,
                   via dev eth1
                            for load balance.

With partial editing:
    For A), nmstate API user need to mark exiting routes as 'absent',
    then add new one.
    For B), nmstate API user just add new one.

        * It's easy for user to add new route entry with
          minimum/incremental data passing to nmstate API.
        * When editing certain entry, user need to search it from
          current state and mark it as absent. This adds a lot more
          works in API user.

        * The API is complexing the common user case -- editing route.

A user will either persist the state he wants or read it when needed from nmstate.

users cannot persist the state they want in the current form because
they cannot express that everything that is not specified should be

At that moment, he can choose to remove and add or just add something new.
I do not understand what complexity is there. We can easily provide SDK helpers to manipulate
the state if that is what they need, after all, it is a dict/map.
At the moment we do not focus on the SDK, but only on the raw API.
With consumption, I am pretty sure we will be able to build a state sdk lib to ease user usage.

With full editing: API user just define what he/she wants.

        * It simple and clear to say in API document about route:
            You get what you asked, nothing else.

        * API user need to define the whole state, which might be
          a headache with 10k+ routes.

Fetching and Setting back on each change from a remote client is very costly,
consider a management system (the user/client) and hundreds of hosts, each with 10k entries.
That does not scale well.

Nmstate does not provide a remote API only a local one. Whatever is
going to provide the remote API could also support partial states. Or
it can be an SDK as you call it. Nevertheless, this would keep the
core (hopefully) simpler. Also it seems to me a lot easier to build
partial state handling on top of something that handles full states
than the other way around. If a program supports partial states, it
cannot distinguish them from full states.

I personally favor the full editing staff and add below functions when
full editing is a real concern in the future:

    * nmstate.netapplier.add()              # Add new stuff
    * nmstate.netapplier.edit()             # Override existing stuff
    * nmstate.netapplier.remove()           # Remove stuff

Any comments and suggestions?

Nmstate is intended to represent a declarative API, not a functional one.
You could suggest that we need to have two versions of apply/set: Partial and Full.
The same as we will probably need to support to versions of show (like netconf does): Config only, and 
Config + Read-Only(Oper State).

We could also propose special magic entries, which represent a collection:
- all-other <interfaces, routes, ip-addresses>
- all-other interfaces of type ethernet
But these are almost identical to the configuration policies which have been proposed through the 
kubernetes-nmstate project.

I would prefer to have the partial state applied whenever it makes sense.
I also think it is safer: As an example, VDSM controls only a portion of the host interfaces, it does not 
touch parts
which have not been explicitly configured in the management system. This provides a flexibility to the host 
to manage it through two management systems: The oVirt one and the Host deployment one, each having their 
interfaces. When oVirt wants to define something on its owned interfaces, it should not touch and risk the 

How does this work with routes since they are not tied to an interface in oVirt?

The user should mention only the parts it is interested to change, anything else should not change.

It is a valid scenario. But the question is whether this needs to be
handled in the Nmstate core.

Kind regards

Till Maas
Ansible RHEL Networking System Role Maintainer
Red Hat GmbH

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]