[openstack-dev] [Nova] Database changes coming in Grizzly

Vishvananda Ishaya vishvananda at gmail.com
Mon Jan 28 17:27:20 UTC 2013


On Jan 28, 2013, at 2:14 AM, Daniel P. Berrange <berrange at redhat.com> wrote:

> On Fri, Jan 25, 2013 at 01:44:13PM -0800, Vishvananda Ishaya wrote:
>> 
>> On Jan 25, 2013, at 8:38 AM, 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.
>>> 
>>> Daniel
>> 
>> The issue is that last time we merged the code (diablo release), we discovered
>> an issue after the fact and had to patch it back out. Unfortunately the bug
>> was only showing up in multinode installs under load, so we added it back
>> in protected by a config option so we could do some testing with it in larger
>> installs. I don't want to turn it on my default until we are sure that the
>> previous issues are fixed.
> 
> How are we going to be sure it is working reliably though, if it is off
> by default & thus rarely gets exercised ? Can we at least enable it by
> default in DevStack, so that openstack developers are testing the code
> by default, even if production builds won't have it enabled.
> 
> Daniel

Yes we can enable it in devstack. We could even turn it on by default during the
cycle and set it back to off for the final release if we are unsure about it.

Vish




More information about the OpenStack-dev mailing list