Skip to content
This repository was archived by the owner on May 20, 2025. It is now read-only.
This repository was archived by the owner on May 20, 2025. It is now read-only.

Burn an AMI that's not yet listening to the redis queue, but is configured and prepared to do so #175

@amywieliczka

Description

@amywieliczka

Previously:

  • To get a high-stage worker, you had to run create_worker.yml and then run provision_worker.yml with the high-stage parameter.
  • To get a regular worker, you just had to run start_worker.yml

Now:

  • To get a high-stage worker, you have to run start_worker.yml when no jobs are currently running or queued, ssh to the new worker, run /usr/local/bin/stop-rqworker.sh, modify /var/local/rqworker/rqw-settings.py, and then run /usr/local/bin/start-rqworker.sh
  • To get a regular worker, you just run start_worker.yml

Proposed Solution:

  • We maintain one worker AMI that is configured to listen to the redis queue, but is not actively listening, so that when a worker is started, it doesn't automatically start picking up jobs right away.
  • We modify start_ami.yml to not only start the worker, but also, once the worker is up, instructs the worker to start listening to the redis queues: 'normal-stage', 'low-stage'
  • We create a new ansible playbook such as start_high_stage_ami.yml to start the worker, and, once the worker is up, instruct the worker to start listening to the redis queue: 'high-stage'
  • We modify create_worker_ami.yml to instruct the "template worker" to stop listening to the redis queue before burning a new AMI

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions