Open Stack

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