Support custom scripts for automatically manipulating objects

[jeremystretch]

Environment

• Python version: 3.5.2
• NetBox version: 2.6.2

Proposed Functionality

Extend NetBox to allow users to run custom scripts natively within the UI, in a similar fashion to how reports are used today. This is essentially a mechanism for integrating standalone scripts into the NetBox UI and API.

For example, a developer might write a script to automatically populate the appropriate devices and prefixes for a new site being deployed. The script would prompt a user for several variables as a web form, and when submitted the script will run, using the provided data to automatically build objects in NetBox.

This idea was split from #1364 (deployment templates) and covers much of its scope. However, we opted to keep #1364 open as an FR for a more user-friendly feature in the future (one which does not require custom scripting).

Use Case

Custom scripts can be used for many things, such as:

• Populating the necessary objects for a new site from a standard design
• Migrating a set of objects through a series of complex bulk operations
• Cleaning up or removing data which does not conform to validation rules

Database Changes

This remains to be determined, though it likely will not require any database changes.

External Dependencies

None

[sdktr]

Very cool idea! Is this functionality intended method of invocation GUI only? Or do you plan to add API endpoints for it as well?
Might be a slippery-slope regarding what the consumer should be able to handle itself or let Netbox handle for him. On the other hand keeping logic in one place (like a netbox-script) independent of the consumer sounds tempting as well..

[darcynz]

This looks fantastic and will greatly enable Netbox.

Wishful thinking, but it would add to its versatility if the scripts could be triggered by or linked to
the webhook functionality.

Imagine that might open / create other problems.

[jeremystretch]

Or do you plan to add API endpoints for it as well?

I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release.

[sdktr]

Or do you plan to add API endpoints for it as well?

I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release.

That sounds like a smooth plan to fuel feedback and adoption