<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 7, 2014 at 7:53 AM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 07/07/2014 12:00, Michael Still a écrit :<br>
<div class="">> I think you'd be better of requesting an exception for your spec than<br>
> splitting the scheduler immediately. These refactorings need to happen<br>
> anyways, and if your scheduler work diverges too far from nova then<br>
> we're going to have a painful time getting things back in sync later.<br>
><br>
> Michael<br>
<br>
<br>
</div>Hi Michael,<br>
<br>
Indeed, whatever the outcome of this discussion is, the problem is that<br>
the 2nd most important spec for isolating the scheduler<br>
(<a href="https://review.openstack.org/89893" target="_blank">https://review.openstack.org/89893</a> ) is not yet approved, and we only<br>
have 3 days left.<br>
<br>
<Teaser> There is a crucial architectural choice to be done in that spec<br>
so we need to find a consensus and make sure everybody is happy with<br>
that, as we can't go on a spec and later on discover that the<br>
implementation is having problems because of an unexpected issue </Teaser><br></blockquote><div><br></div><div>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Sylvain<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Mon, Jul 7, 2014 at 5:28 PM, Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>> wrote:<br>
>> Le 04/07/2014 10:41, Daniel P. Berrange a écrit :<br>
>>> On Thu, Jul 03, 2014 at 03:30:06PM -0400, Russell Bryant wrote:<br>
>>>> On 07/03/2014 01:53 PM, Sylvain Bauza wrote:<br>
>>>>> Hi,<br>
>>>>><br>
>>>>> ==<br>
>>>>> tl; dr: A decision has been made to split out the scheduler to a<br>
>>>>> separate project not on a feature parity basis with nova-scheduler, your<br>
>>>>> comments are welcome.<br>
>>>>> ==<br>
>>>> ...<br>
>>>><br>
>>>>> During the last Gantt meeting held Tuesday, we discussed about the<br>
>>>>> status and the problems we have. As we are close to Juno-2, there are<br>
>>>>> some concerns about which blueprints would be implemented by Juno, so<br>
>>>>> Gantt would be updated after. Due to the problems raised in the<br>
>>>>> different blueprints (please see the links there), it has been agreed to<br>
>>>>> follow a path a bit different from the one agreed at the Summit : once<br>
>>>>> B/ is merged, Gantt will be updated and work will happen in there while<br>
>>>>> work with C/ will happen in parallel. That means we need to backport in<br>
>>>>> Gantt all changes happening to the scheduler, but (and this is the most<br>
>>>>> important point) until C/ is merged into Gantt, Gantt won't support<br>
>>>>> filters which decide on aggregates or instance groups. In other words,<br>
>>>>> until C/ happens (but also A/), Gantt won't be feature-parity with<br>
>>>>> Nova-scheduler.<br>
>>>>><br>
>>>>> That doesn't mean Gantt will move forward and leave all missing features<br>
>>>>> out of it, we will be dedicated to feature-parity as top priority but<br>
>>>>> that implies that the first releases of Gantt will be experimental and<br>
>>>>> considered for testing purposes only.<br>
>>>> I don't think this sounds like the best approach. It sounds like effort<br>
>>>> will go into maintaining two schedulers instead of continuing to focus<br>
>>>> effort on the refactoring necessary to decouple the scheduler from Nova.<br>
>>>> It's heading straight for a "nova-network and Neutron" scenario, where<br>
>>>> we're maintaining both for much longer than we want to.<br>
>>> Yeah, that's my immediate reaction too. I know it sounds like the Gantt<br>
>>> team are aiming todo the right thing by saying "feature-parity as the<br>
>>> top priority" but I'm concerned that this won't work out that way in<br>
>>> practice.<br>
>>><br>
>>>> I strongly prefer not starting a split until it's clear that the switch<br>
>>>> to the new scheduler can be done as quickly as possible. That means<br>
>>>> that we should be able to start a deprecation and removal timer on<br>
>>>> nova-scheduler. Proceeding with a split now will only make it take even<br>
>>>> longer to get there, IMO.<br>
>>>><br>
>>>> This was the primary reason the last gantt split was scraped. I don't<br>
>>>> understand why we'd go at it again without finishing the job first.<br>
>>> Since Gantt is there primarily to serve Nova's needs, I don't see why<br>
>>> we need to rush into a split that won't actually be capable of serving<br>
>>> Nova needs, rather than waiting until the prerequisite work is ready.<br>
>>><br>
>>> Regards,<br>
>>> Daniel<br>
>> Thanks Dan and Russell for the feedback. The main concern about the<br>
>> scheduler split is when<br>
>> it would be done, if Juno or later. The current changes I raised are<br>
>> waiting to be validated, and the main blueprint (isolate-scheduler-db)<br>
>> is not yet validated before July 10th (Spec Freeze) so there is risk<br>
>> that the efforts would be done on the K release (unless we get an<br>
>> exception here)<br>
>><br>
>> -Sylvain<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>