Le 19/08/2014 14:51, Sylvain Bauza a écrit :
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.
So, we held Gantt meeting today, and minutes are here
http://eavesdrop.openstack.org/meetings/gantt/2014/gantt.2014-08-19-15.00.html
The concern I raised above has been heavily discussed there and we ended
up deciding that we need to clean up the interfaces in between Scheduler
and Resource Tracker (ie. cleary identify an API for modeling resources
sent to Scheduler, not a bare JSON blob containing nested dicts)
So, long story short, we identified PoC from Jay Pipes [6] as a good
starting point for the resource models and classes that would contain
the resource usage. Jay and I volunteered for porting that model into
Nova soon and see how it will integrate with existing.
That means that the validated effort on a scheduler library
(bp/scheduler-lib, here [1]) are still considered for Juno (and need to
be reviewed), while patches related to [2] (bp/isolate-scheduler-db) are
considered on-hold until we identify the proper way, as said previously.
On the other hand, ERT discussion is decoupled from the scheduler split
discussion and will be delayed until Extensible Resource Tracker owner
(Paul Murray) is back from vacation.
In the mean time, we're considering new patches using ERT as
non-acceptable, at least until a decision is made about ERT.
-Sylvain
[6] https://review.openstack.org/#/c/103598/
-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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev