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