Open Stack

On 09/05/2014 05:20 PM, John Garbutt wrote:
> On 5 September 2014 13:59, Nikola Đipanov <ndipanov at redhat.com> wrote:
>> Since this did not get an 'Approved' as of yet, I want to make sure that
>> this is not because the number of sponsors. 2 core members have already
>> sponsored it, and as per [1] cores can sponsor their own FFEs so that's 3.
> 
> While I am no fan of that idea, this was already in the gate, so 2
> cores should be more than enough.
> 
> Mikal has said I could approve FFEs in his absence, but given the
> conflict in the thread, I want to leave this approval to him :)
> 

FWIW - I really don't think there is any conflict in the thread.

Not a single person spoke up against it, and if the only argument is
that we are adding additional data to the 'compute_node' table, blocking
on that at this point would be irrational as the migration that does it
is already merged.

But I am fine with leaving the final decision on Mikal, to be honest I
was rather confused when I saw no feedback from him when I opened my
inbox this morning, neither positive or negative.

Thanks,
N.

> I know its 10 patches, but I think we can try resolve the discussion
> on the thread, and look to approve this on Monday morning, and still
> make it before the deadline. Do shout up if that seems impossible
> and/or stupid.
> 
> Thanks,
> John
> 
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044669.html
>>
>> On 09/04/2014 01:58 PM, Nikola Đipanov wrote:
>>> Hi team,
>>>
>>> I am requesting the exception for the feature from the subject (find
>>> specs at [1] and outstanding changes at [2]).
>>>
>>> Some reasons why we may want to grant it:
>>>
>>> First of all all patches have been approved in time and just lost the
>>> gate race.
>>>
>>> Rejecting it makes little sense really, as it has been commented on by a
>>> good chunk of the core team, most of the invasive stuff (db migrations
>>> for example) has already merged, and the few parts that may seem
>>> contentious have either been discussed and agreed upon [3], or can
>>> easily be addressed in subsequent bug fixes.
>>>
>>> It would be very beneficial to merge it so that we actually get real
>>> testing on the feature ASAP (scheduling features are not tested in the
>>> gate so we need to rely on downstream/3rd party/user testing for those).
>>>
>>> Thanks,
>>>
>>> Nikola
>>>
>>> [1]
>>> http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/virt-driver-numa-placement.rst
>>> [2]
>>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/virt-driver-numa-placement,n,z
>>> [3] https://review.openstack.org/#/c/111782/
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>