Open Stack

On Mon, Jul 7, 2014 at 7:53 AM, Sylvain Bauza <sbauza at redhat.com> wrote:

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

Just like the rest of OpenStack the spec repos don't have nearly enough
reviewers. I don't even see any +1s  on that spec from anyone involved in
the gantt effort. If you would like to help get that spec approved we need
more reviewers in the nova-specs repo.


> -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
> >
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/93113f85/attachment.html>