Open Stack

Thanks for your thoughts Radomir. The nova api in question is memoized so
it'll only be called once per request. Caching it for longer would be a
very good idea, but that then brings into play deeper knowledge than I have
about how long to cache things like nova extension configuration. Also, I
looked into this see whether we could use a nicer existing memoizing system
(one with a timeout, that doesn't use weakref and will clean out stale
entries), but none of them will handle the existence of the varying request
parameter, so more work would be required to build our own solution. It's
still something I'd like to see done.

But that's not really the point of this email, as you note :)



On 29 August 2014 19:46, Radomir Dopieralski <openstack at sheep.art.pl> wrote:

> On 29/08/14 04:22, Richard Jones wrote:
>
>
> > Very recently I attempted to fix a simple bug in which a Panel was being
> > displayed when it shouldn't have been. The resultant 5-line fix ended up
> > breaking 498 of the 1048 unit tests in the suite. I estimated that it
> > would take about a week's effort to address all the failing tests. For
> > more information see
> > <http://mechanicalcat.net/richard/log/Python/When_testing_goes_bad>
>
> Having read that, I can't help but comment that maybe, just maybe,
> making an API call on each an every request to Horizon is not such a
> great idea after all, and should be very well thought out, as it is
> costly. In particular, it should be investigated if the call could be
> made only on some requests? That would have the side effect of breaking
> much fewer tests.
>
> But I agree that mox is horrible in that it effectively freezes the
> implementation details of the tested unit, instead of testing its behavior.
>
> --
> Radomir Dopieralski
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/474924b4/attachment.html>