Nautobot 12 factor adherence

Environment

• Python version: NA
• Nautobot version: 1.2.0b1

With the implementation of #1079 we have removed the ability to set several settings from environment variables when those settings were migrated to the DB. I like the DB configuration and we need it but it seems some functionality was lost by removing the default os.getenv calls from the default nautobot_config.py.j2. This seems to drift a bit from the 12-factor app philosophy. This probably isn’t really a huge deal (especially with the set of variables that were moved to the DB) but it does impact the docker deployments out there as we can no longer specify env vars for these settings.

I’d like to come up with a plan for all settings/config variables, not just this small subset, so we can be consistent and if possible meet the 12-factor guidance.

Today the docker build uses the nautobot_config.py.j2 template to build its default config and appends some logging configuration to it. We can come up with some logic for the docker entrypoint to pull env vars and inject them into a custom nautobot_config, build a completely custom nautobot_config.py for the containers, or we could move the env var parsing to the defaults in settings.py which would allow the DB to override them.

I’d also like to come up with something that would allow for the configuration of other settings vars like LDAP or SSO for the docker container. This may require a hybrid solution. Looking for some ideas/feedback on how we can maintain this long term.

[nniehoff]

Just a quick note that it’s still quite possible to manage the settings as environment variables, just not with a completely vanilla nautobot_config.py freshly generated from the built-in template since it no longer includes those by default. Probably that’s what you’re alluding to when you mention a custom nautobot_config for the container build, but I just wanted to make that explicit. Thanks! 😃

Right my point is I would consider the config generated by nautobot-server init an out of the box setup. The functionality of using env variables is now gone from the out of the box setup. So do we want to re-enable that out of the box ability perhaps by checking env vars in settings.py by default or do we want to have the nautobot_config.py used by the docker image be completely unique from the nautobot_config.py.j2 template. We already have nautobot_config.append.py which we tack on the end of the stock configuration which I really don’t like.

I’d like to keep feature parity as much as possible with Nautobot core but at the same time, we now have bundled all of the extras with the container so it makes sense to provide methods of configuring LDAP/SSO etc out of the box with the container. I can see this pushing us towards a separate nautobot_config.py or perhaps adding to the current nautobot_config.append.py. The problem I see happening with a separate docker config is that we now have the potential to override DB settings which may be undesirable as well. This is why I like the idea of doing it in settings.py. If we have default values and query the env from settings.py we can still override those with the DB. This behavior would then be consistent between docker and the core Nautobot.

[glennmatthews]

Brainstorming here - we could adopt something similar to the Nautobot Jobs configuration pattern, where each relevant setting has an associated “override” flag - if “override” is false, we take the configuration from settings.py/nautobot_config.py (which in turn is potentially derived from an environment variable), while if “override” is true, we use the configuration as specified via the admin UI and stored in the database instead. This would allow us to have our cake and eat it too as far as being able to change settings either in the environment/nautobot_config.py or via the admin UI/database and still have clear expectations about which one takes precedence when they mismatch.

This would almost certainly require us forking django-constance or implementing equivalent functionality from scratch, but it might still be worth considering?