Le 24/07/2014 02:11, Michael Still a écrit :
> In that case this exception is approved. The exception is in the form
> of another week to get the spec merged, so quick iterations are the
> key.
> Cheers,
> Michael

Thanks Michael, greatly appreciated.


> On Wed, Jul 23, 2014 at 5:31 PM, Sylvain Bauza <sba...@redhat.com> wrote:
>> Le 23/07/2014 01:11, Michael Still a écrit :
>>> This spec freeze exception only has one core signed up. Are there any
>>> other cores interested in working with Sylvain on this one?
>>> Michael
>> By looking at
>> https://etherpad.openstack.org/p/nova-juno-spec-priorities, I can see
>> ndipanov as volunteer for sponsoring this blueprint.
>> -Sylvain
>>> On Mon, Jul 21, 2014 at 7:59 PM, John Garbutt <j...@johngarbutt.com> wrote:
>>>> On 18 July 2014 09:10, Sylvain Bauza <sba...@redhat.com> wrote:
>>>>> Hi team,
>>>>> I would like to put your attention on https://review.openstack.org/89893
>>>>> This spec targets to isolate access within the filters to only Scheduler
>>>>> bits. This one is a prerequisite for a possible split of the scheduler
>>>>> into a separate project named Gantt, as it's necessary to remove direct
>>>>> access to other Nova objects (like aggregates and instances).
>>>>> This spec is one of the oldest specs so far, but its approval has been
>>>>> delayed because there were other concerns to discuss first about how we
>>>>> split the scheduler. Now that these concerns have been addressed, it is
>>>>> time for going back to that blueprint and iterate over it.
>>>>> I understand the exception is for a window of 7 days. In my opinion,
>>>>> this objective is targetable as now all the pieces are there for making
>>>>> a consensus.
>>>>> The change by itself is only a refactoring of the existing code with no
>>>>> impact on APIs neither on DB scheme, so IMHO this blueprint is a good
>>>>> opportunity for being on track with the objective of a split by
>>>>> beginning of Kilo.
>>>>> Cores, I leave you appreciate the urgency and I'm available by IRC or
>>>>> email for answering questions.
>>>> Regardless of Gantt, tidying up the data dependencies here make sense.
>>>> I feel we need to consider how the above works with upgrades.
>>>> I am happy to sponsor this blueprint. Although I worry we might not
>>>> get agreement in time.
>>>> Thanks,
>>>> John
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to