Age | Commit message (Collapse) | Author |
|
|
|
|
|
Make minor corrections to readme
|
|
|
|
* Add stand-alone config_tree renderer
* Add tests for stand-alone config_tree renderer
* Add renderer with reference tree
* Add tests for Config_tree renderer with reftree
* Update config files
* Add refactoring functions and correct tests
|
|
|
|
|
|
Basepath is better be a command line option, since when it's really needed,
having it in the config is pretty much useless.
This reverts commit 377de9472716266bb932813a8f7a7ba9aa1630fb.
|
|
|
|
Right now the primary motivation is ease of testing without installing
any appliance on a real system, but in real appliances, this may be handy
for those who want things in /opt, even if I'm not a fan of /opt
|
|
If we are going to use batteries for numeric_compare, why not take
advantage of the rest.
|
|
|
|
|
|
It was failing because reference tree loader doesn't make guarantess about
the order of children in the resulting tree.
|
|
Findlib package "vyconf" now contains modules required for working with configs,
namely Vytree, Config_tree, Reference_tree, Valur_checker, Curly_lexer, and Curly_parser.
Renderer will go there too. Migration scripts and convertors/analyzers/whatever utilities
that need to read and write config files will link with it.
The "vyconf.vyconf-config" package is for working with vyconfd.conf config.
Config scripts written in OCaml, the shell, and the non-interactive client can use it to
read the system config if the user didn't use options for socket location and so on.
The "vyconf.vyconf-client" package is for the Protobuf over UNIX sockets protocol clients.
|
|
* T231: Load directory of interface definitions
* T231: Add ounit package to merlin config
* T231: Add tests for loading dir of definitions
* squash! T231: Load directory of interface definitions
* squash! T231: Add tests for loading dir of definitions
|
|
Also, this will work for bare ocaml REPL too, specifically for utop
you don't need to load topfind since it does that by default.
|
|
|
|
Add a bit more build and setup instruction
|
|
Add a readymade utop environment
|
|
|
|
|
|
|
|
|
|
Right now it uses a SHA-1 sum of 30 random bits. I hope that's secure enough.
|
|
I wonder if the user field should be an UID rather than name.
|
|
|
|
|
|
a default.
|
|
|
|
|
|
I have no idea why I did not do it this way from the start.
|
|
|
|
|
|
The Message module contains read and write functions that take care of
the wire protocol, which sends a 4 byte length header before every message.
They take a bytes buffer and don't care about its contents.
The Vyconf_client module has high level functions for interfacing with vyconfd.
Functions for creating a socket and creating a server loop are in Startup.
The rest is, for now at least, right in vyconfd.
Notes:
Message.read/write probably should be wrapped in Lwt_io.atomic
We need to find out if it's safe to reuse Pbrt.Encoder.t or we really
should create it every time.
|
|
|
|
instead of home-grown equivalents.
|
|
|
|
(whitespace, braces, square brackets, quotes, and hash).
|
|
Allow single quoted strings.
Allow \r's as whitespace.
Set line numbers on \n to enable better error reporting.
Allow any non-reserved characters ([^\s\{\}\[\]\"\']) in identifiers and unquoted values.
|
|
Two tag nodes with the same name ("ethernet eth0 {...} ethernet eth0 {...}")
is an error.
Two leaf nodes with the same name, however, are not an error. Values of the
next nodes are merged into the first one, while all other data (comment and
inactive and ephemeral properties are inherited from the first node.
This mimics the old syntax of multi nodes, so a person who uses the old syntax
out of habit in a handwritten config will get the result they expect.
|
|
|
|
|
|
|
|
|
|
identifiers.
|
|
as opposed to "ethernet { eth0".
Note that "new syntax" for tag nodes, i.e. not using any special syntax
for them is automatically support too, configs will load correctly
since node name/value validation only occurs after parsing is complete.
|
|
that share the same name by merging subsequent nodes into the first one.
Bad thing: the comments of the outer nodes will be lost, but then again
one should attach them to the inner node anyway, in non-pathological cases.
|
|
|
|
that already exists.
|