Open Stack

On 14 April 2014 17:27, Sean Dague <sean at dague.net> wrote:

> On 04/14/2014 12:09 PM, Kyle Mestery wrote:
> > On Mon, Apr 14, 2014 at 10:54 AM, Salvatore Orlando <sorlando at 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
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140414/37995119/attachment.html>