Open Stack

On 09/04/2014 04:51 PM, Murray, Paul (HP Cloud) wrote:
>  
> 
> On 4 September 2014 14:07, Nikola Đipanov <ndipanov at redhat.com> wrote:
> 
> On 09/04/2014 02:31 PM, Sean Dague wrote:
> 
>> On 09/04/2014 07:58 AM, 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).
> 
>> 
> 
>> This statement bugs me. It seems kind of backwards to say we should
> 
>> merge a thing that we don't have a good upstream test plan on and put it
> 
>> in a release so that the testing will happen only in the downstream case.
> 
>> 
> 
>  
> 
> The objective reality is that many other things have not had upstream
> 
> testing for a long time (anything that requires more than 1 compute node
> 
> in Nova for example, and any scheduling feature - as I mention clearly
> 
> above), so not sure how that is backwards from any reasonable point.
> 
>  
> 
> Thanks to folks using them, it is still kept working and bugs get fixed.
> 
> Getting features into the hands of users is extremely important...
> 
>  
> 
>> Anyway, not enough to -1 it, but enough to at least say something.
> 
>> 
> 
>  
> 
> .. but I do not want to get into the discussion about software testing
> 
> here, not the place really.
> 
>  
> 
> However, I do think it is very harmful to respond to FFE request with
> 
> such blanket statements and generalizations, if only for the message it
> 
> sends to the contributors (that we really care more about upholding our
> 
> own myths as a community than users and features).
> 
>  
> 
>  
> 
> I believe you brought this up as one of your justifications for the FFE.
> When I read your statement it does sound as though you want to put
> experimental code in at the final release. I am sure that is not what
> you had in mind, but I am also sure you can also understand Sean's point
> of view. His point is clear and pertinent to your request.
> 
>  
> 
> As the person responsible for Nova in HP I will be interested to see how
> it operates in practice. I can assure you we will do extensive testing
> on it before it goes into the wild and we will not put it into practice
> if we are not happy.
> 

That is awesome and we as a project are lucky to have that! I would not
want things put into practice that users can't use or see huge flaws with.

I can't help but read this as you being OK with the feature going ahead,
though :).

N.

>  
> 
> Paul
> 
>  
> 
> Paul Murray
> 
> Nova Technical Lead, HP Cloud
> 
> +44 117 312 9309
> 
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN Registered No: 690597 England. The contents of this message and
> any attachments to it are confidential and may be legally privileged. If
> you have received this message in error, you should delete it from your
> system immediately and advise the sender. To any recipient of this
> message within HP, unless otherwise stated you should consider this
> message and attachments as "HP CONFIDENTIAL".
> 
>  
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>