[openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking
Sylvain Bauza
sbauza at redhat.com
Tue Aug 19 12:51:38 UTC 2014
Hi,
As it was also stated in
http://www.stillhq.com/openstack/juno/000012.html, we expect to finish
the prerequisites for Scheduler split by Juno. That requires to merge
two blueprints, one with the spec validated but patches still under
review [1] and one with the spec still subject to debates [2]
During this cycle, we discussed a lot how to update Scheduler with
Compute Node stats, and the proposal we made (with a +2 on the spec) was
to make use of Extensible Resource Tracker [3] to make that work easily
without having to create new DB or Objects fields.
That said, it seems Extensible Resource Tracker (ERT) is still subject
to discussions [4], where a revert change has been proposed [5]
I can understand the concerns raised by that, but that's unfortunate
that we discuss if ERT is good or not by 1 week before Feature Proposal
Freeze, which will happen this Thursday. Indeed, while the changes have
been proposed now some weeks ago, it requires to create new patches by 2
days in order to remove ERT as a dependency from the patches. IIUC,
removing ERT means, with the concern of scheduler split, to create a new
DB compute_node field and a new ComputeNode Object attribute for each
resource (aggregate, instance, flavor) related to the host : that will
generate more work and while the interface will be quite good (one field
for one type), it will have huge payload (one ComputeNode version more,
migrations etc.)
In that condition, I can't hardly see how we can reach the target of
merging all the bits by Juno. That's why I'm coming back to you,
Nova-ists, to know your opinion and what kind of things you would like.
Yeah, I know that's life and life can be hard, but I'm just advocating
advices for getting all of your attention.
-Sylvain
[1] https://review.openstack.org/82778 and
https://review.openstack.org/104556
[2]
https://review.openstack.org/#/q/status:open+topic:bp/isolate-scheduler-db,n,z
[3] https://review.openstack.org/#/c/109643/
[4]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/042709.html
[5] https://review.openstack.org/115218
More information about the OpenStack-dev
mailing list