Open Stack

On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague <sean at dague.net> wrote:

> On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sean Dague [mailto:sean at dague.net]
> >>
> >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:
> >>>
> >>> Keystone is just one service, but we want to run a test, in which it
> >>> is setup in HA – two services running at different versions, using the
> same
> >> DB.
> >>
> >> Let me understand the scenario correctly.
> >>
> >> There would be Keystone Liberty and Keystone Mitaka, both talking to a
> >> Liberty DB?
> >>
> >
> > The DB would be upgraded to Mitaka. From Mitaka onwards, we are making
> only additive schema changes, so that both versions can work simultaneously.
> >
> > Here are the specifics:
> >
> http://docs.openstack.org/developer/keystone/developing.html#online-migration
>
> Breaking this down, it seems like there is a simpler test setup here.
>
> Master keystone is already tested with master db, all over the place. In
> unit tests all the dsvm jobs. So we can assume pretty hard that that works.
>
> Keystone doesn't cross talk to itself (as there are no workers), so I
> don't think there is anything to test there.
>
> Keystone stable working with master db seems like an interesting bit,
> are there already tests for that?
>
>
There are currently no working tests for this and due to a lot of
discussion on the difficulty around this (extensively discussed at the
keystone midcycle), moves towards this type of support have been deferred
to Newton.


> Also, is there any time where you'd get data from Keystone new use it in
> a server, and then send it back to Keystone old, and have a validation
> issue? That seems easier to trigger edge cases at a lower level. Like an
> extra attribute is in a payload in Keystone new, and Keystone old
> faceplants with it.
>
>
The general consensus was that this is a *very* hard problem. And we may
need something like microversions before we can support mixed versions of
keystone behind a single LB. We're likely to say "you can upgrade all
running keystone code, then migrate the db, but running mixed versions wont
be supported" as a starting point.


> The reality is that standing up an HA Proxy Keystone multinode
> environment is going to be pretty extensive amount of work. And when
> things fail, digging out why, is kind of hard. However it feels like
> most of the interesting edges can be tested well at a lower level. And
> is at least worth getting those sorted before biting off the bigger thing.
>

++ We do need this for some other multi-node tesitng (keystone-to-keystone
auth for example). So this benefits more than the SQL-schema specifics.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160205/3805216d/attachment.html>