Move most of NetBox's configuration parameters into the database

[jeremystretch]

Environment

• Python version: 3.7.9
• NetBox version: 2.10.5

Proposed Functionality

Currently, NetBox stores its configuration in (wait for it) configuration.py, as a set of Python variables that get loaded at start time. This FR proposes moving most of this configuration into the database, perhaps as a monolithic JSON object. Critical configuration parameters, such as database and Redis details, would stay in configuration.py.

Use Case

There are a few benefits to this approach. First, it would allow us to provide a convenient UI and API for managing configuration settings. (Arguably that could also be done with a flat file, but using the database simplifies things quite a bit.)

It would also make highly available deployments a bit easier, as the configuration would be synchronized among nodes automatically, without having to set up a separate process to replication the configuration file.

Finally, it could also afford us the ability to store configuration revisions (if we store every configuration as a snapshot). Users could easily make a change, and then revert to a previous configuration if it goes wrong.

Database Changes

We'd probably create a ConfigurationRevision class or something to that effect. It would be a standard model, but might include a bit of additional logic for managing.

External Dependencies

The django-constance library is worth checking out, though it might be overkill.

[bluikko]

I hope that there will be an API or NetBox console access to those configuration parameters in the database.

Otherwise it will make containers and other automated deployments difficult: the database would need to be modified manually.

[jeremystretch]

Going to take a stab at implementing this for v3.0.

[jeremystretch]

After digging into this a bit, I think we need to give more thought to specifically which configuration parameters we want to expose via the UI. Every parameter unique to NetBox itself is easily handled, either using a tool like django-constance or with a custom implementation, but the stock settings defined by Django are trickier. These can't be easily modified in flight due to how Django's settings framework functions.

Many of these built-in settings are fine to keep as static values: database configuration, filesystem paths, etc. However, others are ideal candidates for control via the UI: date and time formatting, for example. I'm just not sure it's worth the effort to pursue support for these.