Possible convergence for URLs for redis with sentinel

[arthurzenika]

Hi,

we've recently started using https://github.com/dealertrack/celery-redis-sentinel
which has a different syntax for pointing to a redis with sentinel : https://github.com/dealertrack/celery-redis-sentinel#usage

Any thoughts on that syntax ? Maybe we could get the projects to converge towards a common syntax ?

[arthurzenika]

Have you tried discussing your schema syntax with the authors/maintainers of https://github.com/andymccurdy/redis-py ?

[ms7s]

Hi @arthurlogilab,

CC @antirez, @miki725

we can definitely define a common syntax for redis sentinel connection strings if there is enough interest. There is also https://www.iana.org/assignments/uri-schemes/prov/redis that might be updated as a result.

I see you also created dealertrack/celery-redis-sentinel#17. Might be good idea to move this discussion to the redis mailing list. I'm in a hurry now, so replying here instead.

The URL (or connection string) scheme in this package was defined so that there is only a single connection string to specify the sentinel hosts instead of having to specify the sentinels separately (as is the case in celery-redis-sentinel), similarly to MongoDB connection strings.

It is worth considering also redis-sentinel instead of redis+sentinel as the scheme because:

• Celery strips the redis+ part from redis+sentinel:// URLs and matches only redis as backend, so if using redis+sentinel:// scheme, you need to replace/monkey-patch the internal redis celery backend
• Celery also sanitizes the result backend URL internally, so the URL specified in CELERY_RESULT_BACKEND must be real valid URL and can only contain a single host:port pair (or just host), so if using multiple host:port pairs, the url must be specified in a separate configuration variable in this case

Personally, I like the redis+sentinel variant slightly more, as it is similar to specifying transports in git urls, for example.