On 14 April 2014 17:27, Sean Dague <s...@dague.net> wrote: > On 04/14/2014 12:09 PM, Kyle Mestery wrote: > > On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando <sorla...@nicira.com> > wrote: > <snip> > >>> The system could be made smarter by storing also a list of "known" > >>> migrations, including whether they were executed or skipped. > >>> > >>> Summarising, in my opinion the approach #2 is not even worth being > >>> considered. Between approach #1 and #3, I'd prefer the simplest one > and vote > >>> for approach #1. > >>> > > > > Thanks for sending out this summary email Salvatore. I agree with your > > summary and I think that option #1 is the way forward to fix this. The > > recovery scripts are a necessity here. I'd like to hear from some > > deployers who may be lurking on their thoughts on this approach as > > well. > > I think it's probably worth while to figure out how many branches > currently exist in the migrations path today? Basically how many > multiverses of neutron schemas might exist at the latest alembic id. > That will help inform how bad things might be. >
To get this number, in theory, you should take in account every migration which could have been potentially skipped. 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. However, this will make things look just a lot worse then what they actually are. > > Grenade happened to trip over one of these, but that's just because of > which defaults we have. I expect that many more could be tripped over > and really burn people trying to make changes in their environment. > The areas where a fix is needed first are those related to "service plugins". So far load balancing, firewall, vpn, metering, and even l3 are treated as such. I will focus on rectifying migrations in these areas. 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. > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev