Open Stack

I think you'd be better of requesting an exception for your spec than
splitting the scheduler immediately. These refactorings need to happen
anyways, and if your scheduler work diverges too far from nova then
we're going to have a painful time getting things back in sync later.

Michael

On Mon, Jul 7, 2014 at 5:28 PM, Sylvain Bauza <sbauza at redhat.com> wrote:
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia