Allow scheduler to receive volume stats when starting service
Filter scheduler relies on volume services to report their stats in
order to make decisions - this nature makes scheduler service a bit
special when it starts because it can't really do anything without
knowning stats of avilable volume backend. So the original
implementation of Filter Scheduler added a hook in init_host() to
ask all volume services to send their stats immediately (volume RPC
call 'publish_service_capabitlies()'), this reduced the chance of a
new volume being set to 'error' state because scheduler has no
knowledge of backends to minimum.
However, commit 65fa80c361f71158cc492dfc520dc4a63ccfa419 moved
init_host() ahead of service RPC initialization because for volume
services, service initialization should be done before the service
starts accepting RPC requests. This change unfortunately invalidated
scheduler service's init_host() because that needs to be done *AFTER*
RPC is ready (a queue is bound to scheduler fanout exchange). The
result is scheduler asks vol service to send update, but it misses
the information it asked for because its queue hasn't been created
and bound to the fanout queue yet. So scheduler always has to wait
for the next update from volume services to be able to work properly.
This change adds a new hook to Manager class called init_hook_with_rpc()
to allow services like scheduler to do something once RPC is ready.
This should restore scheduler's behavior before commit
65fa80c361f71158cc492dfc520dc4a63ccfa419.
Reviewed: https:/ /review. openstack. org/158623 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=60c563f72d2 d6d008fca03f0a0 58941f3807e1a8
Committed: https:/
Submitter: Jenkins
Branch: master
commit 60c563f72d2d6d0 08fca03f0a05894 1f3807e1a8
Author: Zhiteng Huang <email address hidden>
Date: Tue Feb 24 17:05:46 2015 +0800
Allow scheduler to receive volume stats when starting service
Filter scheduler relies on volume services to report their stats in service_ capabitlies( )'), this reduced the chance of a
order to make decisions - this nature makes scheduler service a bit
special when it starts because it can't really do anything without
knowning stats of avilable volume backend. So the original
implementation of Filter Scheduler added a hook in init_host() to
ask all volume services to send their stats immediately (volume RPC
call 'publish_
new volume being set to 'error' state because scheduler has no
knowledge of backends to minimum.
service start | RPC init |
| init_host() |
| --pub_src_
| <------------- |<-vol stats--| (sch fanout)
However, commit 65fa80c361f7115 8cc492dfc520dc4 a63ccfa419 moved
init_host() ahead of service RPC initialization because for volume
services, service initialization should be done before the service
starts accepting RPC requests. This change unfortunately invalidated
scheduler service's init_host() because that needs to be done *AFTER*
RPC is ready (a queue is bound to scheduler fanout exchange). The
result is scheduler asks vol service to send update, but it misses
the information it asked for because its queue hasn't been created
and bound to the fanout queue yet. So scheduler always has to wait
for the next update from volume services to be able to work properly.
service start | init_host() |
| --pub_src_
| (vol stats lost) |<-vol stats--| (sch fanout)
| RPC init |
This change adds a new hook to Manager class called init_hook_ with_rpc( ) 71158cc492dfc52 0dc4a63ccfa419.
to allow services like scheduler to do something once RPC is ready.
This should restore scheduler's behavior before commit
65fa80c361f
Change-Id: If6cf9030eb44c3 9a06ec501ac5c04 9d460782481
Partial-bug: #1409012