Re: Checking libnm/NM version mismatch
On Wed, Nov 27, 2019 at 12:06 PM Till Maas wrote: > Hi, > > Am Mi., 27. Nov. 2019 um 11:02 Uhr schrieb Edward Haas >: > > > > > +1 for a warning. > > knmstate is using libnm in a container and contacting the host NM > service though a mounted socker. > > So in their case, the versions may be different indeed. > > > > I would also like to see it added to the "capabilities" report: > > > > > https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffaba6ce/libnmstate/netinfo.py#L67 > > How do you think it should look like? Should the capabilities report > the libnm version? > Yes, it will be nice to report the NM and libnm versions. It can even report Nmstate version and an optional schema version. Any metadata that can help the client make better decisions. > > Kind regards > Till > > > > > > > > This way the client may decide what to do with the information (like > knmstate). > > -- > Till Maas > He/His/Him > Ansible RHEL Networking System Role Maintainer > > 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 > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Checking libnm/NM version mismatch
On Sat, Nov 23, 2019 at 9:58 AM Thomas Haller via networkmanager-list <
networkmanager-list@gnome.org> wrote:
> On Fri, 2019-11-22 at 21:52 +0100, Till Maas via networkmanager-list
> wrote:
> > Hi,
> >
> > one of the Nmstate ours accidentally used Nmstate on a machine after
> > updating NM without restarting it on CentOS 8. Therefore the system
> > used libnm 1.20 with NM 1.14. This resulted in an error like
> >
> > Connection adding failed: error=nm-connection-error-quark:
> > bridge.vlans: unknown property (7)
> >
> > How can we improve this error message?
>
> NM cannot improve this. Version 1.14 did not know that in the future
> "bridge.vlans" would be a valid property.
>
> The error message is anyway mostly for debugging/logging. An
> application should create settings that it knows are valid (according
> to the targeted NM API). It's not clear how it could meaningfully
> interpret and react on an error.
>
>
>
> > My initial idea would be to compare the versions of NM and libnm in
> > Nmstate and warn/abort if there is a mismatch:
> > AFAICS we can check the NM version with NMClient.get_version() and
> > the
> > libnm version seems to be available with
> >
> > struct.unpack("xBBB", struct.pack(">I", NM.utils_version()))
>
> regarding ">I": the number is in native endianness, not BE.
>
>
> def nm_decode_version(v = None):
> if v is None:
> v = NM.utils_version()
> return ((v >> 16) & 0xFF,
> (v >> 8) & 0xFF,
> (
> v ) & 0xFF)
>
>
> You can also print it in in hex, which gives 0x11503, meaning
> 0x1.0x15.0x3, which is 1.21.3.
>
>
> The major benefit of this encoding is that you can compare versions by
> number.
>
> def nm_encode_version(major, minor, micro):
> return (major << 16) | (minor << 8) | micro
>
> if NM.utils_version() < nm_encode_version(1, 20, 0):
> warn("version missmatch")
>
> or just
>
> if NM.utils_version() < 0x11400: # 1.20.0
> warn("version missmatch")
>
>
>
> > (not so convenient that the version identifiers are in different
> > encodings, to be honest).
>
> Hm, right. The value on D-Bus is a string, so it's nicer to read in d-
> feet/busctl. The value in libnm is numeric, so it's nicer to compare
> the value directly...
>
>
> > How about we add a warning/an error to Nmstate in case the versions
> > mismatch? Do you prefer a warning or an error? Do you have other
> > suggestions?
>
> Sounds fine. A warning might suffice.
>
+1 for a warning.
knmstate is using libnm in a container and contacting the host NM service
though a mounted socker.
So in their case, the versions may be different indeed.
I would also like to see it added to the "capabilities" report:
https://github.com/nmstate/nmstate/blob/e90fd3e07c482ec8e2038c6c65b86809ffaba6ce/libnmstate/netinfo.py#L67
This way the client may decide what to do with the information (like
knmstate).
>
> best,
> Thomas
> ___
> 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
[nmstate] Re-licensing to LGPL
Hello, Due to requests from the OpenStack community, we have been asked to soften nmstate licensing. Re-licensing to LGPL seems to satisfy OpenStack dependency rules. Two tickets have been opened to track this: https://nmstate.atlassian.net/browse/NMSTATE-193 https://nmstate.atlassian.net/browse/NMSTATE-194 Thanks, Edy. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [nmstate] [RFC] ip route partial editing vs whole-state editing
On Thu, Mar 21, 2019 at 11:02 AM Till Maas wrote: > Hi, > > Am Do., 21. März 2019 um 09:16 Uhr schrieb Edward Haas >: > > > > > > > > On Wed, Mar 20, 2019 at 8:35 PM Till Maas wrote: > >> > >> Hi, > >> > >> Am Mi., 20. März 2019 um 18:13 Uhr schrieb Edward Haas via > >> networkmanager-list : > >> > > >> > > >> > > >> > 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. > >> > >> users cannot persist the state they want in the current form because > >> they cannot express that everything that is not specified should be > >> removed. > > > > > > Applications like oVirt does it by persisting the state they are > interested in. The oVirt manager > > is only concern about the networks it manages, not the one it does not. > > It is not interested to manage or control the others and does not > persist non interested entries. > > (although it will show available resources to allow acquiring them into > the pool if needed) > > The fact that oVirt does not care about this does not mean that it > makes sense to limit the Nmstate API to only partial states. > I do not think it is limiting, if you want to develop a full state command (`apply_full`), you are welcome to add it to the requirements and contribute an implementation. I just do not want oVirt to care or somehow touch other resources on the system. > > >> > 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. > >> > >> 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 > &
Re: [nmstate] [RFC] ip route partial editing vs whole-state editing
On Wed, Mar 20, 2019 at 8:35 PM Till Maas wrote: > Hi, > > Am Mi., 20. März 2019 um 18:13 Uhr schrieb Edward Haas via > networkmanager-list : > > > > > > > > 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. > > users cannot persist the state they want in the current form because > they cannot express that everything that is not specified should be > removed. > Applications like oVirt does it by persisting the state they are interested in. The oVirt manager is only concern about the networks it manages, not the one it does not. It is not interested to manage or control the others and does not persist non interested entries. (although it will show available resources to allow acquiring them into the pool if needed) > > 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. > > 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. It currently does not, but it must arrive in one form or the other if we want the api to be useful. Adding another layer of abstraction is not something that makes sense to me, I consider the nmstate API the one that applications should use, remotely or locally. Nevertheless, this would keep the > core (hopefully) simpler. We will still need to read the whole existing state, check if the request is possible, and we will need to recreate the whole thing anyway. There are even cases where the client is of an older version than the server, then the complementary config action is needed anyway. In addition, parameters existing in the provider (NM) and not in the state config we will have to treat like we do today (complement it, or not touch it). I am not convinced it is simpler, it is just a new bunch or new cases to handle. Finally, making it simpler for the core is a secondary objective. It needs to be simpler for the clients, and taking oVirt as the first client example, it will not be simpler to use the full state. 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
Re: [nmstate] [RFC] ip route partial editing vs whole-state editing
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 - 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
Re: [RFC] [nmstate] Linux routing in nmstate
On Tue, Mar 5, 2019 at 9:35 AM Edward Haas wrote:
>
>
> On Tue, Mar 5, 2019 at 9:25 AM Gris Ge wrote:
>
>> On Mon, Mar 04, 2019 at 05:58:01PM +0100, Thomas Haller wrote:
>> > On Mon, 2019-03-04 at 22:11 +0800, Gris Ge wrote:
>> > > * Top tree is 'routes', and subtree is 'ipv4' and 'ipv6'.
>> > >Even the IPv4 and IPv6 route entry are mostly identical, but we
>> > > need
>> > >schema to differentiate the 'destination' address type in a simple
>> > >way.
>> >
>> > Hi,
>> >
>> > {
>> > routes: {
>> > [0] = {
>> > addr-family: ipv4,
>> > ...
>> > },
>> > ...
>> > },
>> > }
>> >
>> > I think the answer is "yes".
>> I agree. But Edward has some concern about how to enforce the
>> 'destination' format if we unified the route, which I think we can lose
>> the schema on the destination to string let runtime do the syntax check.
>>
>
> The issue is with the nmstate clients, not nmstate itself.
> The clients will have to write their own code to make sure they are passing
> the correct thing. schema to code generator would have done that for them
> automatically.
>
As far as I know, existing schema standards do not support changing the
type or format of one
entry based on a different entry value.
> > "protocol" possibly should still be renamed to "source". Or "origin"?
>> The origin is better. Source might confuse with source routing.
>> >
>> > best,
>> > Thomas
>>
>>
>>
>> --
>> Gris Ge
>>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Tue, Mar 5, 2019 at 9:25 AM Gris Ge wrote:
> On Mon, Mar 04, 2019 at 05:58:01PM +0100, Thomas Haller wrote:
> > On Mon, 2019-03-04 at 22:11 +0800, Gris Ge wrote:
> > > * Top tree is 'routes', and subtree is 'ipv4' and 'ipv6'.
> > >Even the IPv4 and IPv6 route entry are mostly identical, but we
> > > need
> > >schema to differentiate the 'destination' address type in a simple
> > >way.
> >
> > Hi,
> >
> > {
> > routes: {
> > [0] = {
> > addr-family: ipv4,
> > ...
> > },
> > ...
> > },
> > }
> >
> > I think the answer is "yes".
> I agree. But Edward has some concern about how to enforce the
> 'destination' format if we unified the route, which I think we can lose
> the schema on the destination to string let runtime do the syntax check.
>
The issue is with the nmstate clients, not nmstate itself.
The clients will have to write their own code to make sure they are passing
the correct thing. schema to code generator would have done that for them
automatically.
> "protocol" possibly should still be renamed to "source". Or "origin"?
> The origin is better. Source might confuse with source routing.
> >
> > best,
> > Thomas
>
>
>
> --
> Gris Ge
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Mon, Mar 4, 2019 at 6:58 PM Thomas Haller wrote:
> On Mon, 2019-03-04 at 22:11 +0800, Gris Ge wrote:
> > Based on feedbacks, this is V2 scheme for review:
> >
> > ```
> > {
> > "routes": {
> > "ipv4": [ # Sorted with 'table-id' then
> > 'destination'
> > {
> > "status": "up",
> > # up or absent(to be removed)
> > # If not defined, use 'up'
> > "table-name": "main",
> > # Empty if no name attached,
> > "table-id": 254,
> > # If not defined, use 'main' route table id
> > "protocol": "dhcp", # "static" or "dhcp"
> > # If not defined, use 'static'
> > "metric": 100,
> > # If not defined, let NetworkManager to
> > decided.
> > "destination": "0.0.0.0/0",
> > # Mandatory
> > "next-hop-iface": "eth0",
> > # Mandatory
> > "next-hop-address": "192.0.2.1"
> > # ^ Empty on point-to-point link
> > },
> > ],
> > "ipv6": [# Sorted with 'table-id' then 'destination'
> > {
> > "status": "up",
> > "table-name": "main",
> > "table-id": 254,
> > "protocol": "router-advertisement",
> > # ^ "static" or "router-advertisement"
> > "metric": 100,
> > "destination": "::/0",
> > "next-hop-iface": "eth0",
> > "next-hop-address": "fe80::1"
> > },
> > ],
> > }
> > }
> > ```
> >
> > Changes since V1:
> >
> > * Top tree is 'routes', and subtree is 'ipv4' and 'ipv6'.
> >Even the IPv4 and IPv6 route entry are mostly identical, but we
> > need
> >schema to differentiate the 'destination' address type in a simple
> >way.
>
> Hi,
>
> I don't think there is any fundamental difference between
>
> {
> ipv4-routes: { ... },
> ipv6-routes: { ... },
> }
>
> and
>
> {
> routes: {
> ipv4: { ... },
> ipv6: { ... },
> },
> }
>
>
> Instead, the more fundamntal question is whether IPv4 and IPv6 routes
> should be merged together and expressed by the same "object"/"type",
> and get a "addr-family" field to differenciate.
>
> {
> routes: {
> [0] = {
> addr-family: ipv4,
> ...
> },
> ...
> },
> }
>
> I think the answer is "yes". It seems better to me to treat routes the
> same on a higher layer, and move the differenciation between address
> families closer the places that care about the difference.
>
It is indeed nicer in terms of human readability, but it is not trivial (or
even possible)
to describe it using a schema.
nmstate clients are usually applications, which will use the schema to
potentially generate
code structures per the language they use.
Having the same key accepting different types (IPv4 vs IPv6 addresses) is
problematic.
Even if you consider these as strings, they still usually have a format
validation and converting
this union to a typed language structures is challenging.
I have also not seen this used with schemas, therefore, I think we should
follow the classic
definition for now, especially when we already have the same for
`interfaces`.
With that said, if we do find it simpler and get feedback that a different
format is better, we can
always change and still keep compatibility through versioning (which we
should introduce eventually).
>
>
>
> > * Add 'status: absent' to simplify the route deletion.
> >
> > * Add comments to show the default value if not defined.
>
> "protocol" possibly should still be renamed to "source". Or "origin"?
>
> +1
> best,
> Thomas
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Fri, Mar 1, 2019 at 9:41 AM Thomas Haller wrote:
> On Thu, 2019-02-28 at 22:40 +0200, Edward Haas via networkmanager-list
> wrote:
> > Thank you Gris.
> > Comments in-line.
> >
> > On Tue, Feb 26, 2019 at 8:56 AM Gris Ge wrote:
> > > Hi Guys,
> > >
> > > Could you review below schema for routing in nmstate before we
> > > start
> > > add routing support in nmstate?
> > >
> > > ```
> >
> > What is the root level key? `routing`?
> >
> > > {
> > > "ipv4-routes": [# Sorted with 'table-id' then
> > > 'destination'
> >
> >
> > ipv4 and ipv6 look identical to me here.
> > It makes sense then to have `route` as the subtree and a `family`
> > entry inside.
> > > {
> > > "table-name": "main", # Empty if no name attached
> > > "table-id": 254,
> > > "protocol": "dhcp", # "static" or "dhcp"
> > > "metric": 100,
> > > "destination": "0.0.0.0/0",
> > > "next-hop-iface": "eth0", # Mandatory
> >
> > This is not mandatory on `iproute2`, it is usually resolved based on
> > the address next hop.
> > I think it is mandatory for p2p links only.
>
> I think it should be mandatory. Kernel or iproute2 may detect certain
> next-hop-interfaces by looking at whether there is a direct route to
> the next hop (on an interface). But that seems fragile to me, and
> something you can do ad-hoc (at the moment when issuing the iproute2
> command), but not so well in a description of the state (which, is
> kinda timeless).
>
> Also, it is mandatory *for a lot* of cases. It's effort to pin down
> exactly when it's mandatory and when not.
>
> Also, a mandatory paramter can later always be relaxed for bing not
> mandatory. But making it mandatory later is an API break.
>
The implementation can require it per its logic, but I prefer the schema to
allow it.
I think that most usages are for simple IP route entries and not P2P ones,
in which
we do not want to be bound to a specific device at the desired state.
If this is supported, changes to the devices names or addresses on them do
not
need to change the route/desired state.
For a user, it also does not require knowledge about which device to use,
the system
will take care of that for him.
>
> best,
> Thomas
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Fri, Mar 1, 2019 at 9:43 AM Thomas Haller wrote: > Hi, > > On Tue, 2019-02-26 at 14:56 +0800, Gris Ge via networkmanager-list > > > "protocol": "dhcp", # "static" or "dhcp" > > "protocol" sounds a bit like iproute2's "protocol" option (struct > rtmsg's rtm_protocol). But I think it's not. > > I would call this "source". > +1 > > > best, > Thomas > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Fri, Mar 1, 2019 at 4:34 AM Gris Ge wrote: > On Thu, Feb 28, 2019 at 10:40:48PM +0200, Edward Haas wrote: > > > > What is the root level key? `routing`? > The root level is 'ipv4-routes' and 'ipv6-routes'. > > Try to save a layer for user to type comparing to ['routing']['routes'] > > The ip version is a detail, I do not think it should be exposed at the root. Please also note that the api users are mostly other applications, so we need a balance between a good programmatic structure and human ease of use. > ipv4 and ipv6 look identical to me here. > > It makes sense then to have `route` as the subtree and a `family` > > entry inside. > OK. And we could auto detect the family if user does not specify it when > applying. > Ahh... in the morning I realized that this is problematic when we need to represent it in a json schema. Usually one key has a single type (and a format is a type I guess). I do not know if we can overcome this. (think of a user that uses a typed language, how will it be described there (type)?) > "next-hop-iface": "eth0", # Mandatory > > > > > > This is not mandatory on `iproute2`, it is usually resolved based on > > the address next hop. > Will remove the mandatory thing. > > > "ipv6-routes": [# Sorted with 'table-id' then > 'destination' > > "protocol": "auto", # "static" or "auto"[1] > > I prefer a more meaningful name, `auto` is problematic. > How about 'ipv6-ra' for router advertisement? > If we will be under an ipv6 subtree, `ra` should be enough (or the full name, router-advertisement). If not, and we have here protocols for both, then +1. > * For future source routing support, we could add top entry as > >'route-rules' or other name to be decided. > > > > routing-->rule will be nice. > Same reason above, save some typing. > > What about adding or deleting an entry. > > Can we use `state` to express existence and absent? > > For cases where there are hundreds of routes, asking the user to > > specify all will not work well. > User could just remove the entry from what he/she got from > `libnmstate.show()`. I don't know why that's hard for user. > Can you elaborate the use case? > We support it explicitly with interfaces. Using show and the apply is valid, but with a large number of routes, it is very traffic and process consuming. But perhaps the main disadvantage is the assumption that the user is reading the state. There are several users which we know today that handle things in one direction only. As a reminder, for the nmstate api we have taken an explicit decision to allow applying snippet configurations. > Thank you very much. > Best regards. > > -- > Gris Ge > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
Thank you Gris.
Comments in-line.
On Tue, Feb 26, 2019 at 8:56 AM Gris Ge wrote:
> Hi Guys,
>
> Could you review below schema for routing in nmstate before we start
> add routing support in nmstate?
>
> ```
>
What is the root level key? `routing`?
{
> "ipv4-routes": [# Sorted with 'table-id' then 'destination'
>
ipv4 and ipv6 look identical to me here.
It makes sense then to have `route` as the subtree and a `family` entry
inside.
> {
> "table-name": "main", # Empty if no name attached
> "table-id": 254,
> "protocol": "dhcp", # "static" or "dhcp"
> "metric": 100,
> "destination": "0.0.0.0/0",
> "next-hop-iface": "eth0", # Mandatory
>
This is not mandatory on `iproute2`, it is usually resolved based on the
address next hop.
I think it is mandatory for p2p links only.
"next-hop-address": "192.0.2.1"
> # ^ Empty on point-to-point link
> },
> ],
> "ipv6-routes": [# Sorted with 'table-id' then 'destination'
> {
> "table-name": "main", # Empty if no name attached
> "table-id": 254,
> "protocol": "auto", # "static" or "auto"[1]
>
I prefer a more meaningful name, `auto` is problematic.
"metric": 100,
> "destination": "::/0",
> "next-hop-iface": "eth0", # Mandatory
>
Same, I do not think it is mandatory.
> "next-hop-address": "fe80::1"
> },
> ],
> }
> ```
>
> Notes:
> * The 'auto' or 'dhcp' route entry will be ignored when applying via
>nmstate.
> * For single route entry with multiple next-hops, nmstate will show it
>as multiple route entries with the same destination.
> * Regarding YANG(RFC-8022) compatibility, we will create a translator
>when we adding YANG support.
> * For future source routing support, we could add top entry as
>'route-rules' or other name to be decided.
>
routing-->rule will be nice.
> * For future support of OSPF, BGP, we could add top entry as 'ospf'
>or 'bgp' to hold their configuration and extend the 'protocol' types
>in above schema.
>
> Any comments or suggestions will be appreciated.
>
What about adding or deleting an entry.
Can we use `state` to express existence and absent?
For cases where there are hundreds of routes, asking the user to specify
all will not work well.
> Thank you very much in advance.
> Best regards.
>
> [1]: The "auto" protocol in "ipv6-routes" means IPv6 Router
> Advertisement.
>
> --
> Gris Ge
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
