Lots of documentation fixes

Changelog

@@ -20,34 +20,36 @@ Important Notes
 
 * Carrot has been replaced with `Kombu`_
 
-    Kombu is the next generation messaging framework for Python.
+    Kombu is the next generation messaging framework for Python,
+    fixing several flaws present in Carrot that was hard to fix
+    without breaking backwards compatibility.
 
-    It fixes a lot of obvious flaws with Carrot that was impossible
-    to fix without breaking backward compatibility, and also it adds,
+    Also it adds:
 
     * First-class support for virtual transports; Redis, Django ORM,
-      SQLAlchemy, Beanstalk, MongoDB and CouchDB.
-    * consistent error handling with introspection,
-    * the ability to ensure that an operation is performed by gracefully
+      SQLAlchemy, Beanstalk, MongoDB, CouchDB and in-memory.
+    * Consistent error handling with introspection,
+    * The ability to ensure that an operation is performed by gracefully
       handling connection and channel errors,
-    * message compression (zlib, bzip2, or custom compression schemes).
+    * Message compression (zlib, bzip2, or custom compression schemes).
 
     This means that `ghettoq` is no longer needed as the
     functionality it provided is already available in Celery by default.
     The virtual transports are also more feature complete with support
     for exchanges (direct and topic).  The Redis transport even supports
-    fanout exchanges which means it handles remote control commands.
+    fanout exchanges so it is able to perform worker remote control
+    commands.
 
 .. _`Kombu`: http://pypi.python.org/pypi/kombu
 
-* Magic keyword arguments deprecated.
+* Magic keyword arguments pending deprecation.
 
     The magic keyword arguments were responsibile for many problems
-    and quirks, notably problems with tasks and decorators, and
-    of course making task keyword arguments unexpectedly special.
+    and quirks: notably issues with tasks and decorators, and name
+    collisions in keyword arguments for the unaware.
 
     It wasn't easy to find a way to deprecate the magic keyword arguments,
-    but we think we have found a solution that makes sense and will not
+    but we think this is a solution that makes sense and it will not
     have any adverse effects on existing code.
 
     The path to a magic keyword argument free world is:
@@ -93,9 +95,16 @@ Important Notes
         a :class:`DeprecationWarning`, and in version 3.0 the
         :mod:`celery.decorators` module will be removed and no longer exist.
 
+        Similarly, the `task.accept_magic_kwargs` attribute will no
+        longer have any effect starting from version 3.0.
+
 * The magic keyword arguments are now available as `task.request`
 
-    This is called *the context*, and is stored in thread-local storage.
+    This is called *the context*.  Thread-local storage is used, and the
+    context contains state that is related to the current request.
+
+    It is mutable and you can add custom attributes that will only be seen
+    by the current task request.
 
     The following context attributes are always available:
 
@@ -113,7 +122,7 @@ Important Notes
     =====================================  ===================================
 
     In addition, the following methods now automatically uses the current
-    context, so you don't have to pass kwargs manually anymore:
+    context, so you don't have to pass `kwargs` manually anymore:
 
         * `task.retry`
         * `task.get_logger`
@@ -123,17 +132,24 @@ Important Notes
 
     This is great news for I/O-bound tasks!
 
-    The first alternative concurrency implementation is for `Eventlet`_,
-    but there is also an experimental `gevent`_ pool.
-
-    To change pool implementation you can use the :option:`-P|--pool` argument
-    to :program:`celeryd`, or change it globally using the
+    To change pool implementations you use the :option:`-P|--pool` argument
+    to :program:`celeryd`, or globally using the
     :setting:`CELERYD_POOL` setting.  This can be the full name of a class,
     or one of the following aliases: `processes`, `eventlet`, `gevent`.
 
     For more information please see the :ref:`concurrency-eventlet` section
     in the User Guide.
 
+    .. admonition:: Why not gevent?
+
+        For our first alternative concurrency implementation we have focused
+        on `Eventlet`_, but there is also an experimental `gevent`_ pool
+        available. This is missing some features, notably the ability to
+        schedule ETA tasks.
+
+        Hopefully the `gevent`_ support will be feature complete by
+        version 2.3, but this depends on user demand (and contributions).
+
 .. _`Eventlet`: http://eventlet.net
 .. _`gevent`: http://gevent.org
 
@@ -169,8 +185,15 @@ Important Notes
     restart workers when they go down (or use this information to optimize
     tasks/autoscaling).
 
-    The event exchange has been renamed from "celeryevent" to "celeryev" so it
-    does not collide with older versions.
+    .. note::
+
+        The event exchange has been renamed from "celeryevent" to "celeryev"
+        so it does not collide with older versions.
+
+        If you would like to remove the old exchange you can do so
+        by executing the following command::
+
+            $ camqadm exchange.delete celeryevent
 
 * `celeryd` now starts without configuration, and configuration can be
   specified directly on the command line.
@@ -193,21 +216,28 @@ Important Notes
 * Remote control commands are now provided by `kombu.pidbox`, the generic
   process mailbox.
 
-* `celery.worker.listener` has been renamed to `celery.worker.consumer`,
-  and `.CarrotListener` is now `.Consumer`.
+* Internal module `celery.worker.listener` has been renamed to
+  `celery.worker.consumer`, and `.CarrotListener` is now `.Consumer`.
 
 * Previously deprecated modules `celery.models` and
-  `celery.management.commands` has now been removed as per the deprecation
+  `celery.management.commands` have now been removed as per the deprecation
   timeline.
 
-* Removed `celery.task.RemoteExecuteTask` and accompanying functions:
-  `dmap`, `dmap_async`, and `execute_remote`.
+* [Security: Low severity] Removed `celery.task.RemoteExecuteTask` and
+    accompanying functions: `dmap`, `dmap_async`, and `execute_remote`.
 
     Executing arbitrary code using pickle is a potential security issue if
     someone gains unrestricted access to the message broker.
 
-    If you really need this functionality, then you can simply add this
-    manually.
+    If you really need this functionality, then you would have to add
+    this to your own project.
+
+* [Security: Low severity] The `stats` command no longer transmits the
+  broker password.
+
+    One would have needed an authenticated broker connection to receive
+    this password in the first place, but sniffing the password at the
+    wire level would have been possible if using unencrypted communication.
 
 .. _v220-news:
 
@@ -266,9 +296,10 @@ News
 
     Inspired by https://gist.github.com/737056
 
-* Can now terminate the worker process processing task remotely.
+* Can now remotely terminate/kill the worker process currently processing
+  a task.
 
-    The revoke remote control command now supports a `terminate` argument
+    The `revoke` remote control command now supports a `terminate` argument
     Default signal is `TERM`, but can be specified using the `signal`
     argument. Signal can be the uppercase name of any signal defined
     in the :mod:`signal` module in the Python Standard Library.
@@ -294,27 +325,30 @@ News
 
 * Improved implementations of `TaskSetResult.join` and `AsyncResult.wait`.
 
-   An `interval` keyword argument has been added to both so the
+   An `interval` keyword argument have been added to both so the
    polling interval can be specified (default interval is 0.5 seconds).
 
-    A `propagate` keyword argument has been added to `result.wait()`,
+    A `propagate` keyword argument have been added to `result.wait()`,
     errors will be returned instead of raised if this is set to False.
 
-    Pollingresults when using the database backend is probabably
-    not a good idea, at least you should increase the polling interval.
+    .. warning::
 
+        You should increase the polling interval when using the
+        database result backend, as frequent polling can result in high
+        database load.
 
-* Worker process PID is now sent with the task-accepted event.
+* The PID of the child worker process accepting a task is now sent as a field
+  with the `task-started` event.
 
-* The start time reported by the multiprocessing worker process is now used
-  when calculating task duration for better accuracy.
+* For better accuracy the start time reported by the multiprocessing worker
+  process is used when calculating task duration.
 
     Previously the time reported by the accept callback was used.
 
-* `celerybeat`: Now has built-in daemonization support using the `--detach`
+* `celerybeat`: New built-in daemonization support using the `--detach`
    option.
 
-* `celeryev`: Now has built-in daemonization support using the `--detach`
+* `celeryev`: New built-in daemonization support using the `--detach`
    option.
 
 * `TaskSet.apply_async`: Now supports custom publishers by using the
@@ -322,10 +356,11 @@ News
 
 * Added :setting:`CELERY_SEND_TASK_SENT_EVENT` setting.
 
-    If enabled an event will be sent out with every task, so monitors can
+    If enabled an event will be sent with every task, so monitors can
     track tasks before the workers receive them.
 
-* `celerybeat`: Now reuses the connection.
+* `celerybeat`: Now reuses the broker connection when applying
+   scheduled tasks.
 
 * The configuration module and loader to use can now be specified on
   the command line.
@@ -352,18 +387,11 @@ News
 
 * CentOS init script for :program:`celeryd` now available in `contrib/centos`.
 
-
-v220-fixes:
+.. _v220-fixes:
 
 Fixes
 -----
 
-* [Security] The `stats` command no longer transmits the broker password.
-
-    One would have needed an authenticated broker connection to receive
-    this password in the first place, but sniffing the password at the
-    wire level would have been possible if using unencrypted communication.
-
 * `celeryev` Curses Monitor: Improved resize handling and UI layout
   (Issue #274 + Issue #276)
 
@@ -394,7 +422,7 @@ Fixes
 
     This means we now rely completely on setuptools entrypoints.
 
-.. v220-experimental:
+.. _v220-experimental:
 
 Experimental
 ------------

FAQ

@@ -56,10 +56,14 @@ Is Celery dependent on pickle?
 **Answer:** No.
 
 Celery can support any serialization scheme and has support for JSON/YAML and
-Pickle by default. You can even send one task using pickle, and another one
-with JSON seamlessly, this is because every task is associated with a
-content-type. The default serialization scheme is pickle because it's the most
-used, and it has support for sending complex objects as task arguments.
+Pickle by default. And as every task is associated with a content type, you
+can even send one task using pickle, and another using JSON.
+
+The default serialization format is pickle simply because it is
+convenient as it supports sending complex Python objects as task arguments.
+
+If you need to communicate with other languages you should change
+to a serialization format that is suitable for that.
 
 You can set a global default serializer, the default serializer for a
 particular Task, or even what serializer to use when sending a single task
@@ -84,8 +88,11 @@ Do I have to use AMQP/RabbitMQ?
 
 **Answer**: No.
 
-You can also use Redis or an SQL database, see `Using other
-queues`_.
+You can also use Redis, Beanstalk, CouchDB, MongoDB or an SQL database,
+see `Using other queues`_.
+
+These "virtual transports" may have limited broadcast and event functionality.
+For example remote control commands only works with AMQP and Redis.
 
 .. _`Using other queues`:
     http://ask.github.com/celery/tutorials/otherqueues.html
@@ -247,16 +254,25 @@ Why won't my Periodic Task run?
 How do I discard all waiting tasks?
 ------------------------------------
 
-**Answer:** Use :func:`~celery.task.control.discard_all`, like this:
+**Answer:** You can use celeryctl to purge all configured task queues::
+
+        $ celeryctl purge
+
+or programatically::
+
+        >>> from celery.task.control import discard_all
+        >>> discard_all()
+        1753
+
+If you only want to purge messages from a specific queue
+you have to use the AMQP API or the :program:`camqadm` utility::
 
-    >>> from celery.task.control import discard_all
-    >>> discard_all()
-    1753
+    $ camqadm queue.purge <queue name>
 
 The number 1753 is the number of messages deleted.
 
 You can also start :mod:`~celery.bin.celeryd` with the
-:option:`--discard` argument which will accomplish the same thing.
+:option:`--purge` argument, to purge messages when the worker starts.
 
 .. _faq-messages-left-after-purge:
 
@@ -420,11 +436,12 @@ What features are not supported when not using an AMQP broker?
 This is an incomplete list of features not available when
 using the virtual transports:
 
-    * The `header` exchange type.
+    * Remote control commands (supported only by Redis).
 
-    * immediate
+    * Monitoring with events may not work in all virtual transports.
 
-    * mandatory
+    * The `header` and `fanout` exchange types
+        (`fanout` is supported by Redis).
 
 .. _faq-tasks:
 
@@ -567,8 +584,9 @@ See :doc:`userguide/routing` for more information.
 Can I change the interval of a periodic task at runtime?
 --------------------------------------------------------
 
-**Answer**: Yes. You can override `PeriodicTask.is_due` or turn
-`PeriodicTask.run_every` into a property:
+**Answer**: Yes. You can use the Django database scheduler, or you can
+override `PeriodicTask.is_due` or turn `PeriodicTask.run_every` into a
+property:
 
 .. code-block:: python
 

docs/contributing.rst

@@ -156,8 +156,6 @@ issue tracker.
 * Flask-Celery: http://github.com/ask/flask-celery/issues
 * Celery-Pylons: http://bitbucket.org/ianschenck/celery-pylons/issues
 * Kombu: http://github.com/ask/kombu/issues
-* Carrot: http://github.com/ask/carrot/issues
-* Ghettoq: http://github.com/ask/ghettoq/issues
 
 If you are unsure of the origin of the bug you can ask the
 :ref:`mailing-list`, or just use the Celery issue tracker.

docs/getting-started/first-steps-with-celery.rst

@@ -29,10 +29,10 @@ like this:
         return x + y
 
 
-All Celery tasks are classes that inherits from the
-:class:`~celery.task.base.Task` class.  In this example we're using a
-decorator that wraps the add function in an appropriate class for us
-automatically.
+Behind the scenes the `@task` decorator actually creates a class that
+inherits from :class:`~celery.task.base.Task`.  The best practice is to
+only create custom task classes when you want to change generic behavior,
+and use the decorator to define tasks.
 
 .. seealso::
 

docs/homepage/index.html

@@ -67,19 +67,24 @@ pageTracker._trackPageview();
         It is focused on real-time operation, but supports scheduling as well.</p>
 
         <p>The execution units, called tasks, are executed concurrently on a single or
-        more worker servers. Tasks can execute asynchronously (in the background) or synchronously
+        more worker servers using multiprocessing, <a href="http://eventlet.net">Eventlet</a>,
+        or <a href="http://gevent.org">gevent</a>. Tasks can execute asynchronously (in the background) or synchronously
         (wait until ready).</p>
 
-        <p>Celery is already used in production to process millions of tasks a day.</p>
+        <p>Celery is used in production systems to process millions of tasks a day.</p>
 
         <p>Celery is written in Python, but the protocol can be implemented in any
         language.
         It can also <a href="http://celeryq.org/docs/userguide/remote-tasks.html"
         >operate with other languages</a> using webhooks.</p>
 
-        <p>The recommended message broker is <a href="http://rabbitmq.com/">RabbitMQ</a>,
-        but support for <a href="http://redisdb.com/">Redis</a> and databases
-        is also available.</p>
+    <p>The recommended message broker is <a href="http://rabbitmq.com/">RabbitMQ</a>,
+        but limited support for <a href="http://redisdb.com/">Redis</a>, <a
+            href="http://kr.github.com/beanstalkd/">Beanstalk</a>, <a
+            href="http://www.mongodb.org/">MongoDB</a>, <a
+            href="http://couchdb.apache.org/">CouchDB</a>, and databases
+        (using <a href="http://www.sqlalchemy.org/">SQLAlchemy</a> or the <a
+            href="http://djangoproject.com">Django ORM</a>) is also available.</p>
 
         Celery is easy to integrate with Django, Pylons and Flask, using
         the <a href="http://pypi.python.org/pypi/django-celery">django-celery</a>,

docs/includes/introduction.txt

@@ -14,16 +14,18 @@ distributed message passing.  It is focused on real-time operation,
 but supports scheduling as well.
 
 The execution units, called tasks, are executed concurrently on one or
-more worker nodes.  Tasks can execute asynchronously (in the background) or
-synchronously (wait until ready).
+more worker nodes using multiprocessing, `Eventlet`_ or `gevent`_.  Tasks can
+execute asynchronously (in the background) or synchronously
+(wait until ready).
 
-Celery is already used in production to process millions of tasks a day.
+Celery is used in production systems to process millions of tasks a day.
 
 Celery is written in Python, but the protocol can be implemented in any
 language.  It can also `operate with other languages using webhooks`_.
 
-The recommended message broker is `RabbitMQ`_, but support for `Redis`_ and
-databases (`SQLAlchemy`_) is also available.
+The recommended message broker is `RabbitMQ`_, but limited support for
+`Redis`_, `Beanstalk`_, `MongoDB`_, `CouchDB`_ and
+databases (using `SQLAlchemy`_ or the `Django ORM`_) is also available.
 
 Celery is easy to integrate with `Django`_, `Pylons`_ and `Flask`_, using
 the `django-celery`_, `celery-pylons`_ and `Flask-Celery`_ add-on packages.
@@ -31,7 +33,13 @@ the `django-celery`_, `celery-pylons`_ and `Flask-Celery`_ add-on packages.
 .. _`RabbitMQ`: http://www.rabbitmq.com/
 .. _`Redis`: http://code.google.com/p/redis/
 .. _`SQLAlchemy`: http://www.sqlalchemy.org/
-.. _`Django`: http://djangoproject.org/
+.. _`Django`: http://djangoproject.com/
+.. _`Django ORM`: http://djangoproject.com/
+.. _`Eventlet`: http://eventlet.net/
+.. _`gevent`: http://gevent.org/
+.. _`Beanstalk`: http://kr.github.com/beanstalkd/
+.. _`MongoDB`: http://mongodb.org/
+.. _`CouchDB`: http://couchdb.apache.org/
 .. _`Pylons`: http://pylonshq.com/
 .. _`Flask`: http://flask.pocoo.org/
 .. _`django-celery`: http://pypi.python.org/pypi/django-celery
@@ -52,8 +60,8 @@ This is a high level overview of the architecture.
 
 .. image:: http://cloud.github.com/downloads/ask/celery/Celery-Overview-v4.jpg
 
-The broker delivers tasks to the worker servers.
-A worker server is a networked machine running `celeryd`.  This can be one or
+The broker delivers tasks to the worker nodes.
+A worker node is a networked machine running `celeryd`.  This can be one or
 more machines depending on the workload.
 
 The result of the task can be stored for later retrieval (called its
@@ -89,33 +97,37 @@ Features
 ========
 
     +-----------------+----------------------------------------------------+
-    | Messaging       | Supported brokers include `RabbitMQ`_, `Stomp`_,   |
-    |                 | `Redis`_, and most common SQL databases.           |
+    | Messaging       | Supported brokers include `RabbitMQ`_, `Redis`_,   |
+    |                 | `Beanstalk`_, `MongoDB`_, `CouchDB`_, and popular  |
+    |                 | SQL databases.                                     |
     +-----------------+----------------------------------------------------+
-    | Robust          | Using `RabbitMQ`, celery survives most error       |
+    | Fault-tolerant  | Excellent configurable error recovery when using   |
+    |                 | `RabbitMQ`, ensures your tasks are never lost.     |
     |                 | scenarios, and your tasks will never be lost.      |
     +-----------------+----------------------------------------------------+
     | Distributed     | Runs on one or more machines. Supports             |
-    |                 | `clustering`_ when used in combination with        |
-    |                 | `RabbitMQ`_. You can set up new workers without    |
-    |                 | central configuration (e.g. use your dads laptop   |
-    |                 | while the queue is temporarily overloaded).        |
+    |                 | broker `clustering`_ and `HA`_ when used in        |
+    |                 | combination with `RabbitMQ`_.  You can set up new  |
+    |                 | workers without central configuration (e.g. use    |
+    |                 | your grandma's laptop to help if the queue is      |
+    |                 | temporarily congested).                            |
     +-----------------+----------------------------------------------------+
-    | Concurrency     | Tasks are executed in parallel using the           |
-    |                 | `multiprocessing` module.                          |
+    | Concurrency     | Concurrency is achieved by using multiprocessing,  |
+    |                 | `Eventlet`_, `gevent` or a mix of these.           |
     +-----------------+----------------------------------------------------+
     | Scheduling      | Supports recurring tasks like cron, or specifying  |
     |                 | an exact date or countdown for when after the task |
     |                 | should be executed.                                |
     +-----------------+----------------------------------------------------+
-    | Performance     | Able to execute tasks while the user waits.        |
+    | Latency         | Low latency means you are able to execute tasks    |
+    |                 | *while the user is waiting*.                       |
     +-----------------+----------------------------------------------------+
     | Return Values   | Task return values can be saved to the selected    |
     |                 | result store backend. You can wait for the result, |
     |                 | retrieve it later, or ignore it.                   |
     +-----------------+----------------------------------------------------+
     | Result Stores   | Database, `MongoDB`_, `Redis`_, `Tokyo Tyrant`,    |
-    |                 | `AMQP`_ (high performance).                        |
+    |                 | `Cassandra`, or `AMQP`_ (message notification).    |
     +-----------------+----------------------------------------------------+
     | Webhooks        | Your tasks can also be HTTP callbacks, enabling    |
     |                 | cross-language communication.                      |
@@ -125,11 +137,15 @@ Features
     |                 | Rate limits can be set for each task type, or      |
     |                 | globally for all.                                  |
     +-----------------+----------------------------------------------------+
-    | Routing         | Using AMQP you can route tasks arbitrarily to      |
-    |                 | different workers.                                 |
+    | Routing         | Using AMQP's flexible routing model you can route  |
+    |                 | tasks to different workers, or select different    |
+    |                 | message topologies, by configuration or even at    |
+    |                 | runtime.                                           |
     +-----------------+----------------------------------------------------+
-    | Remote-control  | You can rate limit and delete (revoke) tasks       |
-    |                 | remotely.                                          |
+    | Remote-control  | Worker nodes can be controlled from remote by      |
+    |                 | using broadcast messaging.  A range of built-in    |
+    |                 | commands exist in addition to the ability to       |
+    |                 | easily define your own. (AMQP/Redis only)          |
     +-----------------+----------------------------------------------------+
     | Monitoring      | You can capture everything happening with the      |
     |                 | workers in real-time by subscribing to events.     |
@@ -160,18 +176,15 @@ Features
     |                 | enabling the ability to poll task status using     |
     |                 | Ajax.                                              |
     +-----------------+----------------------------------------------------+
-    | Error e-mails   | Can be configured to send e-mails to the           |
+    | Error E-mails   | Can be configured to send e-mails to the           |
     |                 | administrators when tasks fails.                   |
     +-----------------+----------------------------------------------------+
-    | Supervised      | Pool workers are supervised and automatically      |
-    |                 | replaced if they crash.                            |
-    +-----------------+----------------------------------------------------+
 
 
 .. _`clustering`: http://www.rabbitmq.com/clustering.html
+.. _`HA`: http://www.rabbitmq.com/pacemaker.html
 .. _`AMQP`: http://www.amqp.org/
 .. _`Stomp`: http://stomp.codehaus.org/
-.. _`MongoDB`: http://www.mongodb.org/
 .. _`Tokyo Tyrant`: http://tokyocabinet.sourceforge.net/
 
 .. _celery-documentation:

docs/includes/resources.txt

@@ -50,7 +50,10 @@ You are highly encouraged to participate in the development
 of `celery`. If you don't like Github (for some reason) you're welcome
 to send regular patches.
 
-See also the Contributing section in the Documentation.
+Be sure to also read the `Contributing to Celery`_ section in the
+documentation.
+
+.. _`Contributing to Celery`: http://ask.github.com/celery/contributing.html
 
 .. _license:
 

docs/index.rst

@@ -12,20 +12,19 @@ Contents:
 
     getting-started/index
     userguide/index
+
+.. toctree::
+    :maxdepth: 1
+
     configuration
     cookbook/index
-    community
     contributing
+    community
     tutorials/index
     faq
-
-.. toctree::
-    :maxdepth: 1
-
     changelog
     reference/index
     internals/index
-    links
 
 
 Indices and tables

docs/links.rst

@@ -1,46 +0,0 @@
-.. _links:
-
-===================
- Interesting Links
-===================
-
-.. _links-celery:
-
-celery
-------
-
-* IRC logs from `#celery` (Freenode):
-    http://botland.oebfare.com/logger/celery/
-
-.. _links-amqp:
-
-AMQP
-----
-
-* `RabbitMQ-shovel`: Message Relocation Equipment (as a plug-in to RabbitMQ)
-
-* `Shovel`_: An AMQP Relay (generic AMQP shovel)
-
-.. _`RabbitMQ-shovel`: http://bit.ly/b1hVW2
-
-.. _`Shovel`: http://bit.ly/xFEde
-
-.. _links-rabbitmq:
-
-RabbitMQ
---------
-
-* `Trixx`_: Administration and Monitoring tool for `RabbitMQ`_ (in
-    development).
-
-* `Cony`_: HTTP based service for providing insight into running
-    `RabbitMQ`_ processes.
-
-* `RabbitMQ Munin Plug-ins`_: Use `Munin`_ to monitor `RabbitMQ`_, and alert
-    on critical events.
-
-.. _`Trixx`: http://github.com/aaronfeng/trixx/tree/master
-.. _`Cony`: http://github.com/gmr/Cony/tree/master
-.. _`RabbitMQ`: http://rabbitmq.com/
-.. _`RabbitMQ Munin Plug-ins`: http://github.com/ask/rabbitmq-munin/
-.. _`Munin`: http://munin.projects.linpro.no/

docs/userguide/monitoring.rst

@@ -1,8 +1,8 @@
 .. _guide-monitoring:
 
-==================
- Monitoring Guide
-==================
+=================================
+ Monitoring and Management Guide
+=================================
 
 .. contents::
     :local:
@@ -22,6 +22,7 @@ Workers
 
 .. _monitoring-celeryctl:
 
+
 celeryctl: Management Utility
 -----------------------------
 
@@ -54,6 +55,14 @@ Commands
     Note that you can omit the name of the task as long as the
     task doesn't use a custom result backend.
 
+* **purge**: Purge messages from all configured task queues.
+    ::
+        $ celeryctl purge
+
+    .. warning::
+        There is no undo for this operation, and messages will
+        be permanently deleted!
+
 * **inspect active**: List active tasks
     ::
 
@@ -486,7 +495,7 @@ Task Events
 
     Sent when the worker receives a task.
 
-* `task-started(uuid, hostname, timestamp)`
+* `task-started(uuid, hostname, timestamp, pid)`
 
     Sent just before the worker executes the task.
 

docs/userguide/periodic-tasks.rst

@@ -80,7 +80,8 @@ Available Fields
 
     Execution options (:class:`dict`).
 
-    This can be any argument supported by :meth:`~celery.execute.apply_async`,
+    This can be any argument supported by
+    :meth:`~celery.task.base.Task.apply_async`,
     e.g. `exchange`, `routing_key`, `expires`, and so on.
 
 * `relative`

docs/userguide/tasks.rst

@@ -40,11 +40,12 @@ Task options are added as arguments to `task`:
 
 .. _task-request-info:
 
-Task Request Info
-=================
+Context
+=======
 
-The `task.request` attribute contains information about
-the task being executed, and contains the following attributes:
+`task.request` contains information and state related
+the currently excuting task, and must always contain the following
+attributes:
 
 :id: The unique id of the executing task.