<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 15, 2013 at 10:44 PM, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 07/15/2013 11:07 PM, Adam Young wrote:<br>

> On 07/15/2013 05:46 AM, Thomas Goirand wrote:<br>
>> On 07/15/2013 04:32 PM, Stephen Gran wrote:<br>
>>> On 15/07/13 09:26, Thomas Goirand wrote:<br>
>>>> Dolph,<br>
>>>><br>
>>>> If you do that, then you will be breaking Debian packages, as they<br>
>>>> expect Sqlite as the default, for example when using<br>
>>>> DEBIAN_FRONTEND=noninteractive apt-get install keystone (if you choose<br>
>>>> MySQL, then you need to enter admin credentials to setup the db). I<br>
>>>> will<br>
>>>> receive tons of piupart failures reports if we can't upgrade with<br>
>>>> SQLite.<br>
>>>><br>
>>>> I would really be disappointed if this happens, and get into situations<br>
>>>> where I have RC bugs which I can't realistically close by myself.<br>
>>>><br>
>>>> So really, if it is possible, continue to support it, at least from one<br>
>>>> release to the next.<br>
>>> Why not just change the default for Debian?  Sqlite isn't particularly<br>
>>> useful for actual deployments anyway.<br>
>> Because that is the only backend that will work without providing<br>
>> credentials on the keyboard, so it is the only one that will work in a<br>
>> non-interactive session of apt-get (which is used for all automated<br>
>> tests in Debian, including piuparts).<br>
><br>
> That is a really, really, really bad reason.<br>
<br>
</div>Ok, then, I think I didn't express myself correctly, so I will try again.<br>
<br>
In Debian, by policy, any package should be able to be installed using<br>
DEBIAN_FRONTEND=noninteractive apt-get install. What I do in my postinst<br>
is calling db_sync, because that isn't something our users should even<br>
care about, since it can be automated. The final result is that, for<br>
many package like Keystone and Glance, simply doing "apt-get install" is<br>
enough to make it work, without needing any configuration file edition.<br>
I want to be able to keep that nice feature.<br></blockquote><div><br></div><div>"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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If we remove support for upgrading from one version to the next, then<br>
either I should remove the support for this, or make a special case for<br>
when sqlite is in use, and not setup any database in that case.</blockquote><div><br></div><div>As a parallel, we special case sqlite:///:memory: for testing purposes by automatically building the schema from models, without running migrations.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Or the<br>
other option is to completely remove sqlite support (if we remove the<br>
possibility to upgrade, then I believe it should be done), and only do<br>
db_sync whenever the database is setup and working. That would also mean<br>
to not start the daemon either, in such a case. This removes really a<br>
lot of automated package testings, and I don't think it is a bad reason<br>
(don't we have a strong culture of automated testing inside the project?).<br>
<br>
If the support for SQLite (db upgrades) has to go, I will understand and<br>
adapt. I haven't and probably wont find the time for doing the actual<br>
work to support SQLite upgrades, and therefore, it probably is easier<br>
for me to state, though, I believe it is my duty to raise my concerns,<br>
and tell that I do not support this decision.<br></blockquote><div><br></div><div>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!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What direction do you think this should take? Your thoughts?<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<div class=""><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>