<p dir="ltr">Actually no confusion. :-) Joe Gordon just made me realize that I didn't really explain why we had that policy. </p>
<p dir="ltr">That really should have been a follow up to my own post, not yours. Sorry if I made it look like I was arguing with you, which I wasn't.. :-) </p>
<p dir="ltr">We're all good. </p>
<p dir="ltr">Sean Dague<br>
<a href="http://dague.net">http://dague.net</a></p>
<div class="gmail_quote">On Oct 31, 2013 12:12 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/31/2013 11:56 AM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/31/2013 11:23 AM, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/31/2013 08:01 AM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So there is a series of patches starting with -<br>
<a href="https://review.openstack.org/#/c/53417/" target="_blank">https://review.openstack.org/#<u></u>/c/53417/</a> that go back and radically<br>
change existing migration files.<br>
<br>
This is really a no-no, unless there is a critical bug fix that<br>
absolutely requires it. Changing past migrations should be considered<br>
with the same level of weight as an N-2 backport, only done when there<br>
is huge upside to the change.<br>
<br>
I've -2ed the first 2 patches in the series, though that review applies<br>
to all of them (I figured a mailing list thread was probably more useful<br>
than -2ing everything in the series).<br>
<br>
There needs to be really solid discussion about the trade offs here<br>
before contemplating something as dangerous as this.<br>
</blockquote>
<br>
+1<br>
</blockquote>
<br>
There is a very real reason why we have a firm stance on this. There are<br>
a huge number of OpenStack instances out in the field, at all sorts of<br>
different past versions. We really try to promise that you can always<br>
forward upgrade your database.<br>
<br>
If you go back and change an old migration, you have not forked the<br>
past. Some people will have already taken that migration, and they have<br>
one view of the world, others haven't yet, they hit your updated<br>
version, and they now have different database. So 2 people with Havana<br>
would no longer be guaranteed to have the same data model set up by us.<br>
<br>
It's easy to believe that "this change is really straight forward, it<br>
will be exactly the same model", but if it isn't, in any way, exactly<br>
the same (even in a way that we didn't realize yet that it mattered),<br>
you've forked the past. And that makes supporting users in these various<br>
forked versions of the world impossible.<br>
<br>
Migrations are basically idempotent. If you want to clean things up, do<br>
them in a new migration. Don't touch an old one unless it is causing<br>
corruption to someone's data so that fixing it with a future migration<br>
is not an option.<br>
</blockquote>
<br>
LOL, I was +1'ing your thoughts, not +1'ing the proposal to have a solid discussion about the trade-offs :)<br>
<br>
Sorry for the confusion!<br>
-jay<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>