On Mon, Jul 7, 2014 at 7:53 AM, Sylvain Bauza <sba...@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 <sba...@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@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
