Netbox: Separate Caching Redis from Webhooks Redis

Created on 21 Jun 2019  路  1Comment  路  Source: netbox-community/netbox

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

accepted feature

Most helpful comment

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.

>All comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

markve-sa picture markve-sa  路  4Comments

cloos picture cloos  路  3Comments

bellwood picture bellwood  路  3Comments

markve-sa picture markve-sa  路  4Comments

hellerve picture hellerve  路  3Comments