Having the ability to configure a separate Redis connection for the caching purpose and one for the webhooks delivery purpose.
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.
Not necessary
None
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.
Most helpful comment
I could see us mimicking the Django
DATABASEdict in which several configurations can be defined.Something like:
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.