Queue Validation

Queue Validation mechanisms

In Issue #64, we implemented the drupal aegir:validate_queue command (see commits ab3b2d92, 7d76e431, f061785c) along with some testing/debugging mechanisms currently living alongside the “Check connection settings” page (admin/aegir/queue), called “Check task queue”. It works like this:

  1. The form validation code simply confirms that the 2 Celery workers are up and running, by posting an “echo” task to each of them, and waiting for them to respond directly (see links to relayd.py and dispatcherd.py @task.echo functions)
    • note this is the same routine that runs when you click “Check connection settings”, to first validate the workers are up
  2. The new TaskQueueConfigForm::checkQueueValidity() form submit handler actually posts a Celery task onto the queue, which we’ve called queue_valid. Here again, we’ve implemented both a relayd.queue_valid and dispatcherd.queue_valid] routine for each of the workers, and they are triggered in turn. Both use the same technique: set a State API variable to FALSE initially, then call the worker task whose job is to end up setting that same variable to TRUE. After posting the task, the submit handler currently polls the State variable (resetting the cache each time through the wait loop), and returns TRUE when the State variable changes, or FALSE if it times out.
    • In the case of the relayd.queue_valid task, we simply call drupal aegir:queue_valid immediately, validating that we can have the Python Celery task code call out to a drupal aegir command, in turn feeding data back to the frontend Aegir site.
    • In the case of the dispatcherd.queue_valid task, we emulate the “round trip” feedback mechanism, where a backend task in turn posts a Celery task onto the queue for relayd to pick up and process (generally via a drupal aegir console command). In this case, we dispatcherd.validate_queue posts a relayd.validate_queue, which in turn calls the drupal aegir:queue_valid command, just as in the previous step.