On 02/23/2016 06:03 PM, Chris Friesen wrote:
On 02/21/2016 01:56 PM, Jay Pipes wrote:
Yingxin, sorry for the delay in responding to this thread. My comments
inline.
On 02/17/2016 12:45 AM, Cheng, Yingxin wrote:
To better illustrate the differences between shared-state,
resource-provider and legacy scheduler, I’ve drew 3 simplified pictures
[1] in emphasizing the location of resource view, the location of claim
and resource consumption, and the resource update/refresh pattern in
three kinds of schedulers. Hoping I’m correct in the “resource-provider
scheduler” part.
2) Claims of resource amounts are done in a database transaction
atomically
within each scheduler process. Therefore there are no "cache updates"
arrows
going back from compute nodes to the resource-provider DB. The only
time a
compute node would communicate with the resource-provider DB (and thus
the
scheduler at all) would be in the case of a *failed* attempt to
initialize
already-claimed resources.
Can you point me to the BP/spec that talks about this? Where in the
code would we update the DB to reflect newly-freed resources?
I should have been more clear, sorry. I am referring only to the process
of claiming resources and the messages involved in cache updates for
those claims. I'm not referring to freeing resources (i.e. an instance
termination). In those cases, there would still need to be a message
sent to inform the scheduler that the resources had been freed. Nothing
would change in that regard.
For information, the blueprint where we are discussing moving claims to
the scheduler (and away from the compute nodes) is here:
https://review.openstack.org/#/c/271823/
I'm in the process of splitting the above blueprint into two. One will
be for the proposed moving of the filters from the scheduler Python
process to instead by filters on the database query for compute nodes.
Another blueprint will be for the "move the claims to the scheduler" stuff.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
