Python coding guidelines for 1.2.0
In some previous post I was talking about the Python wrapper for the config reading library. However, simply switching to a language that is not Perl will not automatically make that code easy to move to 2.0 when the backend is ready, neither it will automatically improve the design and architecture. It will also improve the code in general, and help keeping it readable and maintainable.
You can find the document here: http://wiki.vyos.net/wiki/Python_config_script_policy
In short:
- Logic for config validation, generating configs, and changing system settings/restarting services must be completely separated
- For any configs that allow nesting (dhcpd.conf, ipsec.conf etc.) template processor must be used (as opposed to string concatenation)
- Functions should not randomly output anything to stdout/stderr
- Code must be unit-testable
Config parser for VyConf/VyOS 2.0
Today I pushed initial implementation of the new config lexer and parser. It already supports nodes and node comments, but doesn't support node metadata (that will be used to mark inactive and ephemeral nodes).
You can read the code (https://github.com/vyos/vyconf/blob/master/src/curly_lexer.mll and https://github.com/vyos/vyconf/blob/master/src/curly_parser.mly) and play with it by loading the .cma's into REPL. Next step is to add config renderer. Once the protobuf schema is ready we can wrap it all into a daemon and finally have something to really play with, rather than just run the unit tests.
Informally, here's what I changed in the config syntax.
Old config
interfaces {
/* WAN interface */
ethernet eth0 {
address 192.0.2.1/24
address 192.0.2.2/24
duplex auto
}
}
New config
interfaces {
ethernet {
/* WAN interface */
eth0 {
address [
192.0.2.1/24;
192.0.2.2/24;
];
duplex auto;
// This kind of comment is ignored by the parser
}
}
}
As you can see, the changes are:
- Leaf nodes are now terminated by semicolons rather than newlines.
- There is syntax for comments that are ignored by the parser
- Multi nodes have the array of values in square brackets.
- Tag nodes do not receive any special formatting.
I suppose the last change may be controversial, because it can lead to somewhat odd-looking constructs like:
interfaces {
ethernet {
eth0 {
vif {
21 {
address 192.0.2.1/24
}
}
}
}
}
If you are really going to miss the old approach to tag nodes (that is "ethernet eth0 {" as opposed to "ethernet { eth0 { ...", let me know and I guess I can come up with something. The main difficulty is that, while this never occurs in configs VyOS config save produces, different tag nodes, e.g. "interfaces ethernet" and "interfaces tunnel" can be intermingled, so for parsing we have to track which ones were already created, and this will make the parser code a lot longer.
I'm pretty convinced that "address 192.0.2.1/24; address 192.0.2.2/24" is simply visual clutter and JunOS-like square bracket syntax will make it cleaner. It also solves the aforementioned problem with interleaved nodes tracking for leaf nodes.
Let me know what you think about the syntax.