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
> problematic:
>
> User case A:
> Current routes: 1.1.1.0/24 via 2.2.2.2 dev eth1
> Desired routes: changed next hope to 3.3.3.3
>
> User case B:
> Current routes: 1.1.1.0/24 via 2.2.2.2 dev eth1
> Desired routes: add another route entry,
> 1.1.1.0/24 via 3.3.3.3 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.
>
> Pro:
> * It's easy for user to add new route entry with
> minimum/incremental data passing to nmstate API.
> Cons:
> * 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.
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.
>
> Pro:
> * It simple and clear to say in API document about route:
> You get what you asked, nothing else.
>
> Cons:
> * 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.
> 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 owner
to manage it through two management systems: The oVirt one and the Host
deployment one, each having their dedicated
interfaces. When oVirt wants to define something on its owned interfaces,
it should not touch and risk the others.
The user should mention only the parts it is interested to change, anything
else should not change.
> Thank you very much.
> Best regards.
>
> --
> Gris Ge
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
