Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a generalized "event" system for acting on model-changes #14132

Closed
arthanson opened this issue Oct 27, 2023 · 0 comments
Closed

Provide a generalized "event" system for acting on model-changes #14132

arthanson opened this issue Oct 27, 2023 · 0 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@arthanson
Copy link
Collaborator

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

@arthanson arthanson added the type: feature Introduction of new functionality to the application label Oct 27, 2023
@arthanson arthanson added this to the v3.7 milestone Oct 27, 2023
@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Oct 30, 2023
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Nov 1, 2023
jeremystretch added a commit that referenced this issue Dec 4, 2023
jeremystretch added a commit that referenced this issue Dec 4, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

2 participants