Installing the App in Nautobot¶

Here you will find detailed instructions on how to install and configure the App within your Nautobot environment.

Prerequisites¶

The app relies on nautobot_plugin_nornir to be installed and both apps to be enabled in your configuration settings.
The latest version of this app is compatible with Nautobot 2.0.0 and higher, see this dedicated page for a full compatibility matrix and the deprecation policy.
Databases supported: PostgreSQL, MySQL

Access Requirements¶

There are no access requirements from external systems to this app.

Install Guide¶

Note

Apps can be installed from the Python Package Index or locally. See the Nautobot documentation for more details. The pip package name for this app is nautobot-golden-config.

The app is available as a Python package via PyPI and can be installed with pip:

pip install nautobot-golden-config

To ensure Nautobot Golden Config is automatically re-installed during future upgrades, create a file named local_requirements.txt (if not already existing) in the Nautobot root directory (alongside requirements.txt) and list the nautobot-golden-config package:

echo nautobot-golden-config >> local_requirements.txt

Once installed, the app needs to be enabled in your Nautobot configuration. The following block of code below shows the additional configuration required to be added to your nautobot_config.py file:

Append "nautobot_golden_config" to the PLUGINS list, and "nautobot_plugin_nornir" if it was not already there (more info here).
Append the "nautobot_golden_config" dictionary to the PLUGINS_CONFIG dictionary, and "nautobot_plugin_nornir" if it was not already there.

PLUGINS = ["nautobot_plugin_nornir", "nautobot_golden_config"]

PLUGINS_CONFIG = {
    "nautobot_plugin_nornir": {
        "nornir_settings": {
            "credentials": "nautobot_plugin_nornir.plugins.credentials.env_vars.CredentialsEnvVars",
            "runner": {
                "plugin": "threaded",
                "options": {
                    "num_workers": 20,
                },
            },
        },
    },
    "nautobot_golden_config": {
        "per_feature_bar_width": 0.15,
        "per_feature_width": 13,
        "per_feature_height": 4,
        "enable_backup": True,
        "enable_compliance": True,
        "enable_intended": True,
        "enable_sotagg": True,
        "enable_plan": True,
        "enable_deploy": True,
        "enable_postprocessing": False,
        "sot_agg_transposer": None,
        "postprocessing_callables": [],
        "postprocessing_subscribed": [],
        "jinja_env": {
            "undefined": "jinja2.StrictUndefined",
            "trim_blocks": True,
            "lstrip_blocks": False,
        },
        # "default_deploy_status": "Not Approved",
        # "get_custom_compliance": "my.custom_compliance.func"
    },
}

Once the Nautobot configuration is updated, run the Post Upgrade command (nautobot-server post_upgrade) to run migrations and clear any cache:

nautobot-server post_upgrade

Then restart (if necessary) the Nautobot services which may include:

Nautobot
Nautobot Workers
Nautobot Scheduler

sudo systemctl restart nautobot nautobot-worker nautobot-scheduler

App Configuration¶

The app behavior can be controlled with the following list of settings:

Note

The enable_backup, enable_compliance, enable_intended, enable_sotagg, enable_plan, enable_deploy, and enable_postprocessing will toggle inclusion of the entire component.

Key	Example	Default	Description
enable_backup	True	True	A boolean to represent whether or not to run backup configurations within the app.
enable_compliance	True	True	A boolean to represent whether or not to run the compliance process within the app.
enable_intended	True	True	A boolean to represent whether or not to generate intended configurations within the app.
enable_sotagg	True	True	A boolean to represent whether or not to provide a GraphQL query per device to allow the intended configuration to provide data variables to the app.
enable_plan	True	True	A boolean to represent whether or not to allow the config plan job to run.
enable_deploy	True	True	A boolean to represent whether or not to be able to deploy configs to network devices.
enable_postprocessing	True	False	A boolean to represent whether or not to generate intended configurations to push, with extra processing such as secrets rendering.
default_deploy_status	"Not Approved"	"Not Approved"	A string that will be the name of the status you want as the default when create new config plans, you MUST create the status yourself before starting the app.
postprocessing_callables	['mypackage.myfunction']	[]	A list of function paths, in dotted format, that are appended to the available methods for post-processing the intended configuration, for instance, the `render_secrets`.
postprocessing_subscribed	['mypackage.myfunction']	[]	A list of function paths, that should exist as postprocessing_callables, that defines the order of application of during the post-processing process.
sot_agg_transposer	"mypkg.transposer"	None	A string representation of a function that can post-process the graphQL data.
per_feature_bar_width	0.15	0.15	The width of the table bar within the overview report
per_feature_width	13	13	The width in inches that the overview table can be.
per_feature_height	4	4	The height in inches that the overview table can be.
jinja_env	{"lstrip_blocks": False}	See Note Below	A dictionary of Jinja2 Environment options compatible with Jinja2.SandboxEnvironment()

Note

platform_slug_map configuration was removed as of the v2.0.0 release of Golden Config, for more information please review the v2 Migration Guide

Note

Over time the compliance report will become more dynamic, but for now allow users to configure the per_* configs in a way that fits best for them.

Note

Defaults for Jinja2 environment settings (jinja_env) are as follows:

    jinja_env = {
        "undefined": "jinja2.StrictUndefined",
        "trim_blocks": True,
        "lstrip_blocks": False,
    }

Custom Dispatcher¶

Please note, that this should only be used in rare circumstances not covered in the previous constance settings, when you are truly "rolling your own" dispatcher. Previously, the dispatcher_mapping covered use cases that are now more easily handled. The only two use cases that should be required are.

Provide support for network drivers not currently supported.
Provide some custom business logic you need.

That being said, if you do fall into one of those use cases, you can set the dispatcher as followed:

PLUGINS_CONFIG = {
    "nautobot_plugin_nornir": {
    },
    "nautobot_golden_config": {
        "custom_dispatcher": {
            "arista_eos": "my_custom.dispatcher.NornirDriver",
            "arbitrary_platform_name": "my_custom.dispatcher.OtherNornirDriver",
        },

    },
}

The format for defining these methods is via the dotted string format that will be imported by Django. For example, the Netmiko Cisco IOS dispatcher is defined as nornir_nautobot.plugins.tasks.dispatcher.cisco_ios.NetmikoCiscoIos. You also must hand any installation of the packaging and assurance that the value you provide is importable in the environment you run it on.