Separate Caching Redis from Webhooks Redis #2684

New Issue

adam · 2025-12-29T18:21:06+01:00

adam commented

2025-12-29 18:21:06 +01:00

Originally created by @cimnine on GitHub (Jun 21, 2019).

Environment

Python version: 3.6
NetBox version: 2.6

Proposed Functionality

Having the ability to configure a separate Redis connection for the caching purpose and one for the webhooks delivery purpose.

Use Case

The Redis required for caching has different requirements regarding data persistency than the Redis for delivering webhooks.

While it doesn't matter for the caching Redis if the data is lost, I would try to avoid data loss for the webhooks Redis.

They also have two different access patterns: One is only ever accessed by one client, i.e. my Netbox instance, while the other is accessed by potentially many clients, i.e. at least one Netbox instance and at least one webhook worker.

And in a container-world this matters: The caching Redis would be an instance that is deployed as a sidecar to the Netbox instance, i.e. in the same pod. The webhooks Redis is a shared instance and would therefore be deployed on it's own, potentially with slaves for redundancy purposes, and definitely have some kind of persistent storage attached.

Therefore it would be nice if I could configure two Redis instances in Netbox, one for caching and one for delivering webhook invocations.

Database Changes

Not necessary

External Dependencies

None

Originally created by @cimnine on GitHub (Jun 21, 2019).  ### Environment * Python version: 3.6 * NetBox version: 2.6  ### Proposed Functionality Having the ability to configure a separate Redis connection for the caching purpose and one for the webhooks delivery purpose.  ### Use Case The Redis required for caching has different requirements regarding data persistency than the Redis for delivering webhooks. While it doesn't matter for the caching Redis if the data is lost, I would try to avoid data loss for the webhooks Redis. They also have two different access patterns: One is only ever accessed by one client, i.e. my Netbox instance, while the other is accessed by potentially many clients, i.e. at least one Netbox instance and at least one webhook worker. And in a container-world this matters: The caching Redis would be an instance that is deployed as a sidecar to the Netbox instance, i.e. in the same pod. The webhooks Redis is a shared instance and would therefore be deployed on it's own, potentially with slaves for redundancy purposes, and definitely have some kind of persistent storage attached. Therefore it would be nice if I could configure two Redis instances in Netbox, one for caching and one for delivering webhook invocations.  ### Database Changes Not necessary  ### External Dependencies None

adam added the status: accepted type: feature labels 2025-12-29 18:21:06 +01:00

adam closed this issue

2025-12-29 18:21:06 +01:00

adam commented

2025-12-29 18:21:06 +01:00

@lampwins commented on GitHub (Jun 21, 2019):

I could see us mimicking the Django DATABASE dict in which several configurations can be defined.

Something like:

REDIS = {
    'webhooks': {
        ...
    },
    'caching': {
        ...
    }
}

The actual connection logic is already duplicated in that we open separate connections for cacheops and rq, so that won't require any additional overhead.

@lampwins commented on GitHub (Jun 21, 2019): I could see us mimicking the Django `DATABASE` dict in which several configurations can be defined. Something like: ``` REDIS = { 'webhooks': { ... }, 'caching': { ... } } ``` The actual connection logic is already duplicated in that we open separate connections for cacheops and rq, so that won't require any additional overhead.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#2684