VyOS 2.0 development digest #7: Python coding guidelines for config scripts in 1.2.0, and config parser for VyConf

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.

14 responses
Yuriy, Daniil thank you so much for the VyOS 2.0 blog to keep us "up to date" and also your commitment to improve the software architecture and usabiltiy with the new "config validation", "generating configs", and "changing system settings". If the new config syntax is easier to maintain, no problem for me as long as the cli-command "show configuration commands" (cli config in flat format) still exists in VyOS 2.0
Robert, "show configuration commands" will indeed be there. I hope we can also extend it to display commands of a diff, rather than a single configs, though first things first. This change also has no effect on the set syntax, it's just a config file syntax change. The new syntax is a lot easier to maintain, but if enough people request the old syntax, we can come up with something. It's not impossible, just annoying enough to consider not doing it if we don't have to.
Long time user of Vyatta and VyOS in both hardware and virtual enviroments, dozens of of EC2 instances as well. Not sure where to ask this question but I saw the post on reddit about updates to 2.0 coming. Our main issue is the bottleneck of packets, any chance of DPDK coming or some other offloading system for routing to save CPU bottlenecks?
I may be a dissenting voice here, but I really don't like that leaf nodes are now terminated by semicolons rather than newlines, and separating interfaces and vifs from their actual number. I think it adds verbosity to the config where its not needed. I get adding the brackets for multiple IPs, but I still vastly prefer the original syntax. The new syntax will take up many more lines than are necessary, and make it less easy to read.
I am mainly doing my config jobs inside the config file, I don't use interactive configuration from command line. For me it is much easier to keep overview over the config using the complete config file. So I do manual changes within the config file and then load this file. The current (V1.x) syntax of the file already is relatively long: Many lines for little content. E.g. each firewall rule take about 10 lines where cisco needs one. But it's ok. The new syntax will make everything even longer. So I don't know if this will be "acceptable" for me... Maybe one gets used to even this. I don't know if I am the only one to work this way. But maybe other would have the same problem with the new syntax. P.S. Thank you very much for your work! P.P.S. If the the parser code really gets that much simpler and easier to maintain, I will support this as I am a developer, too and I am aware of these kind of decisions...
Looks like opinions regarding the tag node syntax are divided. I made a poll on phabricator: https://phabricator.vyos.net/V3 , please cast your vote.
I prefer to avoid multiple level nesting, but do like the use of the semi colon to terminate.
7 visitors upvoted this post.