[openstack-dev] [grenade][keystone] Keystone multinode grenade
morgan.fainberg at gmail.com
Fri Feb 5 16:14:09 UTC 2016
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
> >> 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:
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev