Open Stack

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 :|