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