Open Stack

On 07/15/2013 11:07 PM, Adam Young wrote:
> On 07/15/2013 05:46 AM, Thomas Goirand wrote:
>> On 07/15/2013 04:32 PM, Stephen Gran wrote:
>>> On 15/07/13 09:26, Thomas Goirand wrote:
>>>> Dolph,
>>>>
>>>> If you do that, then you will be breaking Debian packages, as they
>>>> expect Sqlite as the default, for example when using
>>>> DEBIAN_FRONTEND=noninteractive apt-get install keystone (if you choose
>>>> MySQL, then you need to enter admin credentials to setup the db). I
>>>> will
>>>> receive tons of piupart failures reports if we can't upgrade with
>>>> SQLite.
>>>>
>>>> I would really be disappointed if this happens, and get into situations
>>>> where I have RC bugs which I can't realistically close by myself.
>>>>
>>>> So really, if it is possible, continue to support it, at least from one
>>>> release to the next.
>>> Why not just change the default for Debian?  Sqlite isn't particularly
>>> useful for actual deployments anyway.
>> Because that is the only backend that will work without providing
>> credentials on the keyboard, so it is the only one that will work in a
>> non-interactive session of apt-get (which is used for all automated
>> tests in Debian, including piuparts).
> 
> That is a really, really, really bad reason.

Ok, then, I think I didn't express myself correctly, so I will try again.

In Debian, by policy, any package should be able to be installed using
DEBIAN_FRONTEND=noninteractive apt-get install. What I do in my postinst
is calling db_sync, because that isn't something our users should even
care about, since it can be automated. The final result is that, for
many package like Keystone and Glance, simply doing "apt-get install" is
enough to make it work, without needing any configuration file edition.
I want to be able to keep that nice feature.

If we remove support for upgrading from one version to the next, then
either I should remove the support for this, or make a special case for
when sqlite is in use, and not setup any database in that case. Or the
other option is to completely remove sqlite support (if we remove the
possibility to upgrade, then I believe it should be done), and only do
db_sync whenever the database is setup and working. That would also mean
to not start the daemon either, in such a case. This removes really a
lot of automated package testings, and I don't think it is a bad reason
(don't we have a strong culture of automated testing inside the project?).

If the support for SQLite (db upgrades) has to go, I will understand and
adapt. I haven't and probably wont find the time for doing the actual
work to support SQLite upgrades, and therefore, it probably is easier
for me to state, though, I believe it is my duty to raise my concerns,
and tell that I do not support this decision.

What direction do you think this should take? Your thoughts?

Cheers,

Thomas Goirand (zigo)