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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
