Open Stack

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

On Wed, Jul 23, 2014 at 5:31 PM, Sylvain Bauza <sbauza at 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 <john at johngarbutt.com> wrote:
>>> On 18 July 2014 09:10, Sylvain Bauza <sbauza at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>



-- 
Rackspace Australia