Bugzilla

The Pernosco services interfaces with Firefox-CI via pulse exchanges. Currently, they listen to all tasks on the `taskcluster-queue/v1/task-completed` exchange, grab the task definition and filter out to only the tasks that are supported then run their analysis on them.

However, this means their consumers need to process ~10k tasks per hour and if their consumers ever fall over or there's some network problems preventing messages from being delivered, it starts to cause problems in our RabbitMQ instances which can bring the whole Firefox-CI Taskcluster instance to a halt. We're planning some longer term improvements to make sure this won't happen.

But in the shorter term,  a simpler thing we can do is to create a dedicated `pernosco` route on only the tasks that are supported, and only when the `PERNOSCO` env is enabled. This should reduce the volume of tasks from many tens of thousands of tasks per day, to only merely dozens. In effect, it would be moving the logic about which tasks to run analysis on from the Pernosco side over to the Mozilla side.

The Pernosco pulse consumers would need to be updated to use this new exchange rather than the queue service's exchange. So close coordination will be required here.

The Pernosco service interfaces with Firefox-CI via pulse exchanges. Currently, they listen to all tasks on the `taskcluster-queue/v1/task-completed` exchange, grab the task definition and filter out to only the tasks that are supported then run their analysis on them.

However, this means their consumers need to process ~10k tasks per hour and if their consumers ever fall over or there's some network problems preventing messages from being delivered, it starts to cause problems in our RabbitMQ instances which can bring the whole Firefox-CI Taskcluster instance to a halt. We're planning some longer term improvements to make sure this won't happen.

But in the shorter term,  a simpler thing we can do is to create a dedicated `pernosco` route on only the tasks that are supported, and only when the `PERNOSCO` env is enabled. This should reduce the volume of tasks from many tens of thousands of tasks per day, to only merely dozens. In effect, it would be moving the logic about which tasks to run analysis on from the Pernosco side over to the Mozilla side.

The Pernosco pulse consumers would need to be updated to use this new exchange rather than the queue service's exchange. So close coordination will be required here.

The Pernosco service interfaces with Firefox-CI via pulse exchanges. Currently, they listen to all tasks on the `taskcluster-queue/v1/task-completed` exchange, grab the task definition and filter out to only the tasks that are supported then run their analysis on them.

However, this means their consumers need to process ~10k tasks per hour and if their consumers ever fall over or there's some network problems preventing messages from being delivered, it starts to cause problems in our RabbitMQ instances which can bring the whole Firefox-CI Taskcluster instance to a halt. We're planning some longer term improvements to make sure this won't happen.

But in the shorter term,  a simpler thing we can do is to create a dedicated `pernosco` route on only the tasks that are supported, and only when the `PERNOSCO` env is enabled. This should reduce the volume of tasks from many tens of thousands of tasks per day, to merely dozens. In effect, it would be moving the logic about which tasks to run analysis on from the Pernosco side over to the Mozilla side.

The Pernosco pulse consumers would need to be updated to use this new exchange rather than the queue service's exchange. So close coordination will be required here.

The Pernosco service interfaces with Firefox-CI via pulse exchanges. Currently, they listen to all tasks on the `taskcluster-queue/v1/task-completed` exchange, grab the task definition and filter out to only the tasks that are supported then run their analysis on them.

However, this means their consumers need to process ~10k tasks per hour and if their consumers ever fall over or there's some network problems preventing messages from being delivered, it starts to cause problems in our RabbitMQ instances which can bring the whole Firefox-CI Taskcluster instance to a halt. We're planning some longer term improvements to make sure this won't happen.

But in the shorter term,  a simpler thing we can do is to create a dedicated `pernosco` route on only the tasks that are supported, and only when the `PERNOSCO` env is enabled. This should reduce the volume of tasks from many tens of thousands of tasks per day, to merely dozens. In effect, it would be moving the logic around which tasks to run the analysis on from the Pernosco side over to the Mozilla side.

The Pernosco pulse consumers would need to be updated to use this new exchange rather than the queue service's exchange. So close coordination will be required here.

The Pernosco service interfaces with Firefox-CI via pulse exchanges. Currently, they listen to all tasks on the `taskcluster-queue/v1/task-completed` exchange, grab the task definition and filter out to only the tasks that are supported then run their analysis on them.

However, this means their consumers need to process ~10k tasks per hour and if their consumers ever fall over or there's some network problems preventing messages from being delivered, it starts to cause problems in our RabbitMQ instances which can bring the whole Firefox-CI Taskcluster instance to a halt. We're planning some longer term improvements to make sure this won't happen.

But in the shorter term,  a simpler thing we can do is to create a dedicated `pernosco` route on only the tasks that are supported, and only when the `PERNOSCO` env is enabled. This should reduce the volume of tasks from many tens of thousands of tasks per day, to merely dozens. In effect, it would be moving the logic around which tasks to run the analysis on from the Pernosco side over to the Mozilla side.

The Pernosco pulse consumers would need to be updated to use this new exchange rather than the queue service's exchange. Though we can leave the `PERNOSCO` env in place for now to preserve backwards compatibility such that the Pernosco consumers can be updated at a later time.