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

Allow custom fields on webhooks #11936

Closed
abhi1693 opened this issue Mar 9, 2023 · 3 comments
Closed

Allow custom fields on webhooks #11936

abhi1693 opened this issue Mar 9, 2023 · 3 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@abhi1693
Copy link
Member

abhi1693 commented Mar 9, 2023

NetBox version

v3.4.5

Feature type

Data model extension

Proposed functionality

Add CustomFieldsMixin on the Webhook model

Use case

I'd like to implement some extra fields on my webhook which are not a part of standard installation or shoould not be added to the core NetBox code. Like knowing how many instances of webhook receiver are registered on it. Such functionality will allow me to create clustered receivers and I will be able to scale them up/down depending on the load on NetBox.

Since this is my custom requirement, it makes sense for to be able to utilise custom fields as per my requirements.

Database changes

Adds a new field automatically to the Webhook model via the mixin as described above.

External dependencies

No response

@abhi1693 abhi1693 added the type: feature Introduction of new functionality to the application label Mar 9, 2023
@jeremystretch
Copy link
Member

I'm afraid I don't understand your use case. Could you provide an example of what you're trying to implement?

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Mar 9, 2023
@abhi1693
Copy link
Member Author

So, I have a webhook receivers that when online, auto-registers themselves with NetBox by creating relevant webhook object. Now, I'd like to scale such receivers in count befind the same recever ingress. The problem is that I want to maintain a count of how many receivers are listening on the webhook object (can be done using custom field). The count will help me to either scale up or down when needed depending on pending tasks in the queues. I have noticed that when my webhook listeners are processing slowly due to whatever reason, the other tasks on netbox keeps getting piled up and that delays execution by alot. Scaling the rq workers can be a fix but that's temporary and sometimes our en can have 300+ changes on the webhook at once and having that many rq workers can be quite expensive for us to scale to.

This is one such use case for myself wherein a custom field will help me keep metadata for the webhook data.

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels May 4, 2023
@abhi1693 abhi1693 self-assigned this Aug 1, 2023
@abhi1693 abhi1693 added status: accepted This issue has been accepted for implementation and removed needs milestone Awaiting prioritization for inclusion with a future NetBox release labels Aug 1, 2023
@abhi1693 abhi1693 added this to the v3.6 milestone Aug 1, 2023
@jeremystretch
Copy link
Member

It probably makes sense to enable tags for webhooks as well.

abhi1693 added a commit that referenced this issue Aug 1, 2023
jeremystretch added a commit that referenced this issue Aug 1, 2023
* adds custom field on webhook model #11936

* adds tags on webhook model #11936

* Remove extraneous import; revert change to NetBoxModelForm (no longer needed)

---------

Co-authored-by: Jeremy Stretch <jstretch@netboxlabs.com>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 31, 2023
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