Open Stack

> -----Original Message-----
> From: Nikola Đipanov [mailto:ndipanov at redhat.com]
> Sent: Thursday, September 04, 2014 4:22 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-
> driver-numa-placement
> 
> 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.

We (Intel) are as well very interested in this feature and would like to see it land in Juno.  
If FFE is granted we will test this feature before release and work with Nikola on fixing bugs if any are found.

Regards
Przemek

> 
> >
> >
> > 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
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev