Open Stack

I'm not saying it can't be rationalized; I'm saying it is frustrating to me.

My understanding is that Essex is going to be baked into both Ubuntu &
Debian for the long term - 5 years plus.   That's a long time to have to
keep explaining why X is broken; I'd rather just fix X.



On Thu, Mar 29, 2012 at 10:22 AM, David Kranz <david.kranz at qrclab.com>wrote:

>  On 3/29/2012 12:46 PM, Justin Santa Barbara wrote:
>
>  Is there a good way to map back where in the code these calls are coming
>> from?
>
>
>  There's not a great way currently.  I'm trying to get a patch in for
> Essex which will let deployments easily turn on SQL debugging (though this
> is proving contentious); it will have a configurable log level to allow for
> future improvements, and one of the things I'd like to do is add later is
> something like a stack trace on 'problematic' SQL (large row count, long
> query time).  But that'll be in Folsom, or in G if we don't get logging
> into Essex.
>
>  In the meantime, it's probably not too hard to follow the code and infer
> where the calls are coming from.  In the full log, there's a bit more
> context, and I've probably snipped some of that out; in this case the
> relevant code is get_metadata in the compute API service and
> get_instance_nw_info in the network service.
>
>
>>  Regardless, large table scans should be eliminated, especially if the
>> table is mostly read, as the hit on an extra index on insert will be
>> completely offset by the speedups on select.
>
>
>  Agreed - some of these problems are very clear-cut!
>
>  It does frustrate me that we've done so much programming work, but then
> not do the simple stuff at the end to make things work well.  It feels a
> bit like shipping we're shipping C code which we've compiled with -O0
> instead of -O3.
>
>
> Well, in a project with the style of fixed-date release (short-duration
> train-model) that openstack has, I think we have to accept that there will
> never be time to do anything except fight critical bugs "at the end". At
> least not until the project code is much more mature. In projects I have
> managed we always allocated time at the *beginning* of a release cycle for
> fixing some backlogged bugs and performance work. There is less pressure
> and the code is not yet churning. It is also important to have performance
> benchmark tests to make sure new features do not introduce performance
> regressions.
>
>  -David
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120329/ee883344/attachment.html>