OpenStack Compute (nova)

Old scheduler fanout queues are left behind after scheduler restart

Bug #803165 reported by Antony Messerli
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Chris Behrens
OpenStack Compute (nova) 2011.3 "diablo"

Bug Description

Scheduler fanout queues are left behind after restarting the service. They also continue to receive messages in them but they never are cleared out since there is no consumer. scheduler_fanout_02343a6daa044db0bc9e7da9db0f074b is getting consumed in this case, while the other fanout queues are incrementing.

scheduler_fanout_02343a6daa044db0bc9e7da9db0f074b 0
scheduler 0
scheduler.z1-api1 0
scheduler_fanout_57a328c93e0248eab9ba0cd9f1d9f12f 728
scheduler_fanout_bb3f88eab8274c66a17e062cd1989301 741
scheduler_fanout_c7b11d15f74d46edbfee251dfd8488d3 69675

Running rev 1215.

Related branches

lp:~cbehrens/nova/lp803165
Josh Kearney (community): Approve
Brian Lamar (community): Needs Information
Matt Dietz (community): Approve
Ed Leafe (community): Approve
Diff: 15 lines (+5/-0)
1 file modified
nova/rpc.py (+5/-0)
Revision history for this message
Chris Behrens (cbehrens) wrote :

We're missing auto_delete=True on fanout queues... OR... maybe the scheduler fanout queue should use scheduler_fanout_hostname vs scheduler_fanout_UUID.

Changed in nova:
assignee: nobody → Chris Behrens (cbehrens)
status: New → Confirmed
Revision history for this message
Sandy Walsh (sandy-walsh) wrote :

I agree they should be torn down, but is hostname sufficient (what if we run more than 1 scheduler on a box to take advantage of multi-core/cpu?)

Revision history for this message
Chris Behrens (cbehrens) wrote :

Good point. I was just going to set auto_delete=True for now anyway. :). That should solve the issue.

Thierry Carrez (ttx)
Changed in nova:
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Chris Behrens (cbehrens) wrote :

Seems setting exclusive=True is more appropriate. It implies auto-deleting the queue. Since we're using a unique queue name, we're definitely the only consumer, so exclusive access is appropriate.

Changed in nova:
status: Triaged → In Progress
OpenStack Infra (hudson-openstack)
Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → diablo-3
Thierry Carrez (ttx)
Changed in nova:
milestone: diablo-3 → 2011.3
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.