Open Stack

On Mon, Jul 15, 2013 at 10:44 PM, Thomas Goirand <zigo at debian.org> wrote:

> 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.
>

"Make it work" is an entirely different goal than "make a production-ready
deployment." If your goal in using sqlite is just to "make it work" then
I'm not sure that I would expect such an install to survive to the next
release, anyway... rendering migration support as a nice-to-have. I can't
imagine that any end users would be happy with a sqlite-based deployment
for anything other than experimentation and testing.


> 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.


As a parallel, we special case sqlite:///:memory: for testing purposes by
automatically building the schema from models, without running migrations.


> 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.
>

I'm glad you spoke up, as I wasn't aware anyone was dependent on support
for sqlite migrations outside of our own tests. Thanks!


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

I'd still like to pursue dropping support for sqlite migrations, albeit not
as aggressively as I would have preferred. With a stakeholder, I think
it's requisite to continue support through Havana. Perhaps at the fall
summit we can evaluate our position on both alembic and sqlite migrations.


>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130716/2bfaa7fd/attachment.html>