<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 14 April 2014 17:27, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 04/14/2014 12:09 PM, Kyle Mestery wrote:<br>
> On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
</div><snip><br>
<div class="">>>> The system could be made smarter by storing also a list of "known"<br>
>>> migrations, including whether they were executed or skipped.<br>
>>><br>
>>> Summarising, in my opinion the approach #2 is not even worth being<br>
>>> considered. Between approach #1 and #3, I'd prefer the simplest one and vote<br>
>>> for approach #1.<br>
>>><br>
><br>
> Thanks for sending out this summary email Salvatore. I agree with your<br>
> summary and I think that option #1 is the way forward to fix this. The<br>
> recovery scripts are a necessity here. I'd like to hear from some<br>
> deployers who may be lurking on their thoughts on this approach as<br>
> well.<br>
<br>
</div>I think it's probably worth while to figure out how many branches<br>
currently exist in the migrations path today? Basically how many<br>
multiverses of neutron schemas might exist at the latest alembic id.<br>
That will help inform how bad things might be.<br></blockquote><div><br></div><div>To get this number, in theory, you should take in account every migration which could have been potentially skipped.</div><div>Any of these migration is a potential "bisection" point of space-time continuum... and then you'll likely end up with a few tens of thousands of possible configurations.</div>
<div>However, this will make things look just a lot worse then what they actually are.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Grenade happened to trip over one of these, but that's just because of<br>
which defaults we have. I expect that many more could be tripped over<br>
and really burn people trying to make changes in their environment.<br></blockquote><div><br></div><div>The areas where a fix is needed first are those related to "service plugins".</div><div>So far load balancing, firewall, vpn, metering, and even l3 are treated as such. I will focus on rectifying migrations in these areas.</div>
<div>Since migrations are executed conditionally, one thing to deal is that we don't know whether a given migration was executed or not, which makes things interesting, although not hard.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
Samsung Research America<br>
<a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><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></div>