On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague <[email protected]> wrote: > On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote: > > > > > >> -----Original Message----- > >> From: Sean Dague [mailto:[email protected]] > >> > >> 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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
