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
