On Mon, Jul 15, 2013 at 10:44 PM, Thomas Goirand <z...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
