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
