Hi all, === tl;dr: Now that we agree on waiting for the split prereqs to be done, we debate on if ResourceTracker should be part of the scheduler code and consequently Scheduler should expose ResourceTracker APIs so that Nova wouldn't own compute nodes resources. I'm proposing to first come with RT as Nova resource in Juno and move ResourceTracker in Scheduler for K, so we at least merge some patches by Juno. ===
Some debates occured recently about the scheduler split, so I think it's important to loop back with you all to see where we are and what are the discussions. Again, feel free to express your opinions, they are welcome. Le 03/07/2014 19:53, Sylvain Bauza a écrit : > Hi, > > == > tl; dr: A decision has been made to split out the scheduler to a > separate project not on a feature parity basis with nova-scheduler, your > comments are welcome. > == > <snip/> So, based on the feedback consensus, we agreed to wait for all the preparation work to be made before doing the split. That said, now that we're focusing back on the split prereqs, some good talks are coming in about what the Scheduler should express as APIs and what would be consequently owned by the scheduler (and later Gantt). During the Summit, we expressed the boundary in between Scheduler and Nova as the current Scheduler namespace in Nova and where the ResourceTracker would take use of a Scheduler client for updating stats to the Scheduler [1]. In this model, compute nodes would stay as a Nova resource and Scheduler (and later Gantt) would have its own representation of the resources it has to manage. The implementation of this model is https://review.openstack.org/82778 still under review. Note also the spec has been validated 3 months ago [2], so this was planned to delivered for Juno. Based on a review we got on the implementation patch [3], there is now an interesting discussion about if Nova should still keep its own representation of the resources (and consequently should manage all claims for resource usage). The idea of it would be to move the ResourceTracker to the Scheduler namespace and consequently the Scheduler should expose Tracking APIs for claiming/unclaiming usage, so the Compute Manager (and no longer the ResourceTracker) would make use of a Scheduler client. A PoC for seeing the ResourceTracker proxified by a Scheduler client can be found here https://review.openstack.org/105747 As we're now beyond the Nova Specs proposal deadline, that would mean that any spec which would be created would see its implementation merged by K at least. Don't blame me if I'm trying to be pragmatic : at a first glance, I appreciate the idea of having the Tracker moved to the Scheduler, but I'm seeing this as another possible step for the split, not the first one. So my proposal is to say : 1. Move on the existing validated spec and review the existing implementation https://review.openstack.org/82778 2. Create a spec targeted for K to see what would be a world where the tracking of resources is done by the Scheduler 3. If that above spec gets validated, do the necessary work in K to move the line 3(bis). If that above spec gets refused, we are still on the good path for splitting the scheduler Thoughts ? -Sylvain [1] https://etherpad.openstack.org/p/juno-nova-gantt-apis [2] https://review.openstack.org/82133 [3] https://review.openstack.org/#/c/82778/42 > _______________________________________________ > 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