#celery

morning, all

we're trying to move to the 3.1 API for our django site... but the docs are inconsistent on what to pass autodiscover

at some points it's lambda : settings.INSTALLED_APPS, at others it's just settings.INSTALLED_APPS

even within the one page - http://docs.celeryproject.org/en/latest/django/...

Since celeryd is depracated, do I still need to create the /etc/default/celeryd script to daemonize celery is or there another one I need? It's not entirely clear from the docs as it seems to suggest that I still need to create that one.

well, you still need the celery daemon, but how you start it has changed, AIUI

from the docs here, http://docs.celeryproject.org/en/latest/tutoria... it suggests that I still need celeryd/celery beat even though the API has changed to be "celery worker" and "celery beat"

to me it would see there would be a new init scrip to use

This is my first attempt at daemonizing on ubuntu, so appologies in advance for my confusion

we use supervisor, so...

but there are init scripts included somewhere for CentOS at least... and probably others

I keep hearing good things about supervisor, maybe I should look into that?

This is my own app so my options are wide open

so what's the current wisdom on hooking up django's request_finished signal to the tast_postrun event?

asksol: the issue with anonymous tasks not being callable via a group (https://github.com/celery/celery/issues/1744) still applies to chords

I don't have permission to re-open that ticket - can you do it, or should I file a new isssue?

hello everyone

I'm using celery 3.1.7 and am trying to figure out how to configure it so that tasks and results are sent through queues in different vhosts

basically, I'm concerned that a task might get compromised, and an attacker might get the permission to send over the task queue, or read from the results queue

now that I ask the question, I realize it's probably a useless setup ;) if a task is compromised, the attacker will get access to the credentials to connect to both vhosts

well, that was a merry chase

had our celery queues SIGSEGVing after a few minutes

turned out that the junior who'd migrated from 3.0 to 3.1... didn't remove django-celery...