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
