Description
NetBox version
v3.5.6
Feature type
New functionality
Proposed functionality
Refactor and extend the current webhook handler to a more generalized eventing system. There is a proposal #11827 to allow scripts to be run depending on object changes which is similar to how webhooks work. This would make the system more generalized so that these events (signals) can do one or more actions (send webhook or run script) with the ability to more easily add more in the future.
Proposed changes
- add login/logout to the events_queue (not processed by webhooks) but useful for future events
- change webhooks_worker.py to events_worker.py and process_webhooks to process_event this will just call a series of functions defined in settings.py pipeline to process events. One will be defined for webhooks, another for script running. This also allows future processors to easily plug into here.
- change the webhooks list and detail page to be events with an action type (webhook, script)
- Change the edit page to have a dropdown for action (call webhook or run script) and HTMX to switch the form below for HTTP Request (as it is now for webhook) or a script selector for Script type.
- Make a migration to map current webhook table to new events table - the signal object type and CRUD selection and type of action would be in the new event model. The post-details would be in the webhooks table.
Note: This would make a script (and all future event types) only run for the object change if the transaction succeeds - which seems to be the correct method.
From previous Issue #11827:
Establish a mechanism by which a custom script can "attach" to one or more signals, so that the script automatically runs when the signal is received. This will likely need to be done programmatically as scripts are discovered. It should be possible to associate a script with a particular arbitrary signal and optionally only to certain senders for that signal.
We'll need to devise a way to automatically discover scripts, as scripts are currently only loaded as needed (e.g. in response to UI/API requests). Special consideration must also be paid to the execution workflow, to ensure that a catastrophic script error does not interfere with the triggering behavior.
For registration, it may be sufficient to call get_scripts() upon NetBox initialization, and execute a prescribed class method on each discovered script to handle its signal attachment. We'll also need to devise a convention for declaring receiver methods on each script.
Use case
Often it is desirable to automatically execute a custom script in response to the creation, modification, or deletion of a NetBox object (similar to how webhooks function).
Makes the code more DRY with this extension and existing webhooks code.
Also makes it more easily extensible in the future as there are probably more action types beyond webhooks and scripts that would make sense in the future.
Database changes
Need a new events table, new script-event table and modify the existing webhooks table.
External dependencies
No response