Introduce support for NetBox plugins

Environment

• Python version: 3.6
• NetBox version: 2.6.1

Proposed Functionality

This feature request proposes modifying NetBox to support the addition of arbitrary third party plugin applications. The plugins can be installed and configured by end users to extend core NetBox functionality to better suit particular use cases. Plugins will allow users to introduce custom models, API endpoints, and additional business logic.

The plugin architecture is envisioned as follows:

• Plugin source code is pulled into a new /plugins/ directory within the NetBox application root.
• Individual plugins are enabled by adding them to the new PLUGINS parameter in configuration.py.
• Each plugin will package a default configuration, elements of which can be overridden in configuration.py.
• Plugins can introduce new UI and API URLs as /plugins/<plugin>/ and /api/plugins/<plugin/, respectively.
• Each plugin is responsible for its own database schema migrations (if any). Plugins will not be permitted to modify the schema of any models outside the plugin.
• Plugins will be able to register arbitrary links in NetBox’s navigation menu.
• Plugins will be able to act on events within NetBox by receiving Django signals.
• Plugins may optionally specify a minimum and/or maximum version of NetBox which which they are compatible.

Obviously, there’s a lot to figure out here. @lampwins has already done some work in this area, but I wanted to capture it in a feature request to kick off the community discussion.

Use Case

This feature would introduce several benefits:

• Remove the need for users to fork the core NetBox code base in order to extend its functionality
• Provide a standardized, documented path for users to implement customizations
• Relieve demand on the core developer team for new features
• Potentially useful as a “proving ground” for new features: Popular plugins may be adopted into the core

However, there are also certain drawbacks which should be considered:

• The additional care necessary to accommodate plugins may slow general feature development
• General support may be more difficult: Plugins will need to be disabled for troubleshooting core issues
• End users will need to thoroughly vet the plugins they choose to install

Database Changes

This probably won’t require any substantial database schema changes, though more exploration is needed to make a clear determination.

External Dependencies

Probably none

[hellerve]

Hey, I see that this issue isn’t in accepted state yet? What is missing? Can the community do anything to move this forward?

A roadmap would be extremely helpful as well; I understand that this might be a little much to ask, but if you have anything at hand, that’d be great!

[lampwins]

I am happy to see us looking down this path 😃

In the name of transparency, here is the PoC I did for a plugin’s architecture to which Jeremy alluded. It follows many of the points made above. https://github.com/lampwins/netbox/tree/plugins

A couple of thoughts:

• The core team will need to publish extensive documentation on proper plugin architecture and hooks into core functionality. As a part of this, we should better document certain internal mechanisms which are already in place. Specifically, I am thinking, more detail on the base classes we have in the docs, the base templates, and template tags. Obviously, there is a lot more to be included.
• Along those same lines and to expand on the above point, we will need to make out support policy very explicit when it comes to plugins. The core team simply does not have the bandwidth to help user-facing issues with 3rd party plugins. We can only support the core functionality and the plumbing which makes plugins work. Obviously, if the core team were to publish a plugin that would be a different story.
• While I am okay with supporting plugin source being dumped in a known directory, in my implementation, I found it much easier to support plugins which are simply packaged as standard Django apps, and thus available in the python environment (i.e. pip install <plugin>. From a deployment standpoint, it is much easier to deal with this way. As an aside, I would like to explore this same concept for reports at some point.
• I would like to see the rqworker become required, which would make its availability to plugins standard. In the example plugin I wrote in my PoC, I made use of the background worker and it was rather elegant to interface with.

Looking forward to the discussion.