Yes, please, let's support commit-to-commit migrations in all of the projects. Some of us are planning to do continuous deployment instead of more massive migrations.<div><br></div><div>Doug<br><br><div class="gmail_quote">
On Wed, Feb 27, 2013 at 9:09 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>This was discussed in #openstack-dev, as I recall.</div><div><br></div>The goal in these migrations was to support folsom <--> grizzly, not necessarily supporting intermediate milestones. I'm not aware of anyone doing continuous deployments of keystone, if but if migrating commit to commit is the community's expectation, I'm more happy to ensure that happens moving forward -- I just wasn't aware that was a concern here.<br>

<div><br></div><div>Thanks for the feedback, and apologies for any inconvenience!</div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><br></div>-Dolph</div></font></span><div>
<div class="h5">
<br><br><div class="gmail_quote">On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:<br>
> Folks,<br>
><br>
> When looking into an error encountered on a keystone db sync,<br>
> I noticed some apparent strangeness in the way keystone schema<br>
> migrations have been managed.<br>
><br>
> Specifically the *rewriting* of schema migration history, see:<br>
><br>
>   <a href="https://github.com/openstack/keystone/commit/5bc46d86" target="_blank">https://github.com/openstack/keystone/commit/5bc46d86</a><br>
><br>
> In my (albeit imperfect) understanding of sqlalchemy-migrate, this<br>
> reordering seems to defeat the whole purpose of step-wise reversible<br>
> migration.<br>
><br>
> Would it even be possible to migrate a grizzly-2 deployment to<br>
> grizzly-3 with that re-ordering in place?<br>
><br>
> Maybe I've missed something here, but I'd appreciate some clarity<br>
> on what is considered community best practice in terms of changes<br>
> to the migration sequence.<br>
><br>
> Previously I would have assumed something like ...<br>
><br>
> Invariants we maintain:<br>
><br>
>  - DB schemas must always be migrate-able across milestone releases<br>
<br>
</div>(snip good stuff)<br>
<br>
It's more than just across milestone releases, we should support<br>
upgrading from commit to commit. In Nova, at least, we're trying hard to<br>
avoid messing up those who are deploying continuously. I'd expect any<br>
nova-core member to reject this patch immediately.<br>
<br>
What I really don't understand is how this concern wasn't raised in the<br>
review at all:<br>
<br>
  <a href="https://review.openstack.org/19780" target="_blank">https://review.openstack.org/19780</a><br>
<br>
Cheers,<br>
Mark.<br>
<div><div><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div></div></div>
<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>
<br></blockquote></div><br></div>