Open Stack

On 26 January 2013 05:38, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Fri, Jan 25, 2013 at 08:24:08AM -0800, Devananda van der Veen wrote:
>> * Non-blocking-db -
>> https://blueprints.launchpad.net/nova/+spec/non-blocking-db
>>  - Use eventlet's db-pool so that MySQL queries don't block the whole
>> python process.
>>  - Progress: done, but has a known bug (
>> https://bugs.launchpad.net/nova/+bug/1097992 )
>>  - Impact: user-facing. This feature is disabled by default; deployer must
>> choose to enable it.
>
> IMHO this kind of config parameter is really dubious. If the feature
> works then we should enable it so that people testing Grizzly actually
> exercise the code. If it doesn't work there's no point having a config
> parameter to enable it, because the toggling it just gives them a broken
> system. Assuming the known bug gets fixed, IMHO the config parameter
> should be removed so that we get real testing of it by everyone using
> and developing Grizzly, not just the 1 or 2 people who might have
> manually enabled it.

I think there is a lot of value in bringing possibly-harmful changes
like this one as options - we can't predict just what deployers will
do or be running into.

I agree that known-broken things are bad (and we should perhaps just
ignore the option and disable the codepath until the bug is fixed) -
but !known_broken != known_good.

I also agree that once its known_good, we should just have it on and
remove the option; I'm mainly pointing out the benefits of bringing
things in gracefully, which seemed to be missing from the analysis you
have.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services