[dev] Adding SQLite as a new optional dependency
Renato Westphal
renato at opensourcerouting.org
Mon Jun 18 10:41:34 EDT 2018
Hi all,
As part of the work in the new northbound architecture, I implemented
support for configuration rollbacks in FRR. Here's a short demo:
https://gist.github.com/rwestphal/caedd9f3e4888cab2d631cc21967e93d
To make this work, FRR needs to keep track of all committed
configuration transactions in non-volatile memory (so they persist
across reboots). One possibility to implement this would be to store
the transactions using text files in the filesystem. The problem with
this approach is that it would be necessary to write a lot of code to
do things correctly, handling all possible errors (lots of things can
go wrong). Using SQLite we have database transactions, which make
things much easier (either all operations succeed or none do). SQLite
in general provides a much better interface to store and retrieve
transactions, not to mention its high-performance properties. I
consider it to be the right tool for the job. But if anyone has an
objection against using SQLite in FRR please speak up.
Initially SQLite should be added as an optional dependency tied to the
--enable-config-rollbacks configuration option. This way users not
interested on configuration rollbacks won't need to install the new
dependency. We might revisit this in the future if we find other use
cases for SQLite in FRR.
When FRR is built with --enable-config-rollbacks, all daemons will
have a new option to specify the path of the daemon-specific database
file: --db-file (the default is ${localstatedir}/<daemon-name>.db).
The special :memory: filename can be used to open a new in-memory
database (which doesn't persist across reboots or daemon restarts).
I should say that configuration rollbacks will only work for daemons
converted to the new northbound model. Speaking of which, the
Northbound API is almost ready to be submitted as a PR. I'm finishing
to polish the code and writing documentation, my estimation is that
everything should be ready within the following two weeks.
Regards,
--
Renato Westphal
More information about the dev
mailing list