Ladislav Lhotka (3c4aad3f) at 16 Oct 14:00
Merge branch 'donation-button' into master
... and 4 more commits
Regarding the YANG models for DNS stuff, this is basically an uncharted territory. There are folks interested in it (Deutsche Telecom, NLNet Labs, PowerDNS) but no standards yet.
How are updates to the YANG format handled? Is the model itself versioned? If so, how do we support multiple version in
configure(cfg)?
The server (kresd) should publish the data model that it uses, i.e. YANG modules and their revisions, supported optional features etc. This can be done using the YANG module library specification, see RFC 7895. This should be made available to the client.
What is the process for adding, changing or deleting keys in the model? Is the process any different for the
cznic-resolver-commonand
cznic-resolver-knotmodels?
Do you mean adding, changing and deleting nodes in the schema tree? YANG has quite strict rules for this:
The rules are designed to avoid backward incompatible changes and breaking old clients. IMO, these rules are way too strict, and there are now efforts to relax them by introducing semantic versioning.
- YANG-specific fields are absolutely irrelevant to the users and make the config needlessly more complex and increase indentation levels, e.g.:
cznic-resolver-common:dns-resolver,
cznic-resolver-knot:hosts-file, ...
These namespaces such as
cznic-resolver-knot is a price for distributed modularity. The idea is to have parts of the data model common to different implementations, and then some implementation-specific knobs.
- too many indentation levels - it gets tedious to deal with many levels of indentation. e.g. specifying values for a root hint is done on indentation level 6
The design of the data model is completely up to us, including the hierarchy.
This being said, an user interface (including config file) needn't of course follow the data model exactly, just has to be able to map its data to the underlying data model. But for the kresd API extensions, config data corresponding to the YANG schema, be it Lua table or JSON, shouldn't pose any problem.
We can't write to a config file, nor should we. Having different runtime and persistent configuration is just confusing and I don't see what purpose it serves - what are the use cases and for whom? What is the issue with editing a configuration file and restarting the service?
But as it is now, runtime configuration can be changed via Lua, right? If we keep that, as this proposal assumes, it is always possible that the actual configuration differs from the config file.
Most devices permit ephemeral configuration changes (starting from things like
ip route in Linux), and there is nothing inherently wrong with it. I would argue on the contrary that Ansible's way of editing config files remotely is much more brittle than a decent config API. And by the way, Ansible can use such an API, too.
Persistency is a separate issue, and there are several solutions how to do it safely.
Before getting too deep into the details, I would recommend everybody to read RFC 3535, or at least Operator Requirements. They were formulated primarily for the context of IP network (routing/switching) configuration, but I think some/most of them are valid for this case, too.