Open Stack

Le 07/07/2014 12:00, Michael Still a écrit :
> 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


Hi Michael,

Indeed, whatever the outcome of this discussion is, the problem is that
the 2nd most important spec for isolating the scheduler
(https://review.openstack.org/89893 ) is not yet approved, and we only
have 3 days left.

<Teaser> There is a crucial architectural choice to be done in that spec
so we need to find a consensus and make sure everybody is happy with
that, as we can't go on a spec and later on discover that the
implementation is having problems because of an unexpected issue </Teaser>

-Sylvain


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