Le 04/07/2014 10:41, Daniel P. Berrange a écrit : > On Thu, Jul 03, 2014 at 03:30:06PM -0400, Russell Bryant wrote: >> On 07/03/2014 01:53 PM, Sylvain Bauza wrote: >>> 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. >>> == >> ... >> >>> During the last Gantt meeting held Tuesday, we discussed about the >>> status and the problems we have. As we are close to Juno-2, there are >>> some concerns about which blueprints would be implemented by Juno, so >>> Gantt would be updated after. Due to the problems raised in the >>> different blueprints (please see the links there), it has been agreed to >>> follow a path a bit different from the one agreed at the Summit : once >>> B/ is merged, Gantt will be updated and work will happen in there while >>> work with C/ will happen in parallel. That means we need to backport in >>> Gantt all changes happening to the scheduler, but (and this is the most >>> important point) until C/ is merged into Gantt, Gantt won't support >>> filters which decide on aggregates or instance groups. In other words, >>> until C/ happens (but also A/), Gantt won't be feature-parity with >>> Nova-scheduler. >>> >>> That doesn't mean Gantt will move forward and leave all missing features >>> out of it, we will be dedicated to feature-parity as top priority but >>> that implies that the first releases of Gantt will be experimental and >>> considered for testing purposes only. >> I don't think this sounds like the best approach. It sounds like effort >> will go into maintaining two schedulers instead of continuing to focus >> effort on the refactoring necessary to decouple the scheduler from Nova. >> It's heading straight for a "nova-network and Neutron" scenario, where >> we're maintaining both for much longer than we want to. > Yeah, that's my immediate reaction too. I know it sounds like the Gantt > team are aiming todo the right thing by saying "feature-parity as the > top priority" but I'm concerned that this won't work out that way in > practice. > >> I strongly prefer not starting a split until it's clear that the switch >> to the new scheduler can be done as quickly as possible. That means >> that we should be able to start a deprecation and removal timer on >> nova-scheduler. Proceeding with a split now will only make it take even >> longer to get there, IMO. >> >> This was the primary reason the last gantt split was scraped. I don't >> understand why we'd go at it again without finishing the job first. > Since Gantt is there primarily to serve Nova's needs, I don't see why > we need to rush into a split that won't actually be capable of serving > Nova needs, rather than waiting until the prerequisite work is ready. > > Regards, > Daniel
Thanks Dan and Russell for the feedback. The main concern about the scheduler split is when it would be done, if Juno or later. The current changes I raised are waiting to be validated, and the main blueprint (isolate-scheduler-db) is not yet validated before July 10th (Spec Freeze) so there is risk that the efforts would be done on the K release (unless we get an exception here) -Sylvain _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev