<div dir="ltr"><br><div>It seems like an SQL database is a bit overkill for configuration file rollback....</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 18, 2018 at 10:41 AM, Renato Westphal <span dir="ltr"><<a href="mailto:renato@opensourcerouting.org" target="_blank">renato@opensourcerouting.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As part of the work in the new northbound architecture, I implemented<br>
support for configuration rollbacks in FRR. Here's a short demo:<br>
<a href="https://gist.github.com/rwestphal/caedd9f3e4888cab2d631cc21967e93d" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>rwestphal/<wbr>caedd9f3e4888cab2d631cc21967e9<wbr>3d</a><br>
<br>
To make this work, FRR needs to keep track of all committed<br>
configuration transactions in non-volatile memory (so they persist<br>
across reboots). One possibility to implement this would be to store<br>
the transactions using text files in the filesystem. The problem with<br>
this approach is that it would be necessary to write a lot of code to<br>
do things correctly, handling all possible errors (lots of things can<br>
go wrong). Using SQLite we have database transactions, which make<br>
things much easier (either all operations succeed or none do). SQLite<br>
in general provides a much better interface to store and retrieve<br>
transactions, not to mention its high-performance properties. I<br>
consider it to be the right tool for the job. But if anyone has an<br>
objection against using SQLite in FRR please speak up.<br>
<br>
Initially SQLite should be added as an optional dependency tied to the<br>
--enable-config-rollbacks configuration option. This way users not<br>
interested on configuration rollbacks won't need to install the new<br>
dependency. We might revisit this in the future if we find other use<br>
cases for SQLite in FRR.<br>
<br>
When FRR is built with --enable-config-rollbacks, all daemons will<br>
have a new option to specify the path of the daemon-specific database<br>
file: --db-file (the default is ${localstatedir}/<daemon-name><wbr>.db).<br>
The special :memory: filename can be used to open a new in-memory<br>
database (which doesn't persist across reboots or daemon restarts).<br>
<br>
I should say that configuration rollbacks will only work for daemons<br>
converted to the new northbound model. Speaking of which, the<br>
Northbound API is almost ready to be submitted as a PR. I'm finishing<br>
to polish the code and writing documentation, my estimation is that<br>
everything should be ready within the following two weeks.<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888">-- <br>
Renato Westphal<br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a><br>
</font></span></blockquote></div><br></div>