<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote:<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Sean Dague [mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>]<br>
>><br>
>> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:<br>
>>><br>
>>> Keystone is just one service, but we want to run a test, in which it<br>
>>> is setup in HA – two services running at different versions, using the same<br>
>> DB.<br>
>><br>
>> Let me understand the scenario correctly.<br>
>><br>
>> There would be Keystone Liberty and Keystone Mitaka, both talking to a<br>
>> Liberty DB?<br>
>><br>
><br>
> The DB would be upgraded to Mitaka. From Mitaka onwards, we are making only additive schema changes, so that both versions can work simultaneously.<br>
><br>
> Here are the specifics:<br>
> <a href="http://docs.openstack.org/developer/keystone/developing.html#online-migration" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/keystone/developing.html#online-migration</a><br>
<br>
</span>Breaking this down, it seems like there is a simpler test setup here.<br>
<br>
Master keystone is already tested with master db, all over the place. In<br>
unit tests all the dsvm jobs. So we can assume pretty hard that that works.<br>
<br>
Keystone doesn't cross talk to itself (as there are no workers), so I<br>
don't think there is anything to test there.<br>
<br>
Keystone stable working with master db seems like an interesting bit,<br>
are there already tests for that?<br>
<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, is there any time where you'd get data from Keystone new use it in<br>
a server, and then send it back to Keystone old, and have a validation<br>
issue? That seems easier to trigger edge cases at a lower level. Like an<br>
extra attribute is in a payload in Keystone new, and Keystone old<br>
faceplants with it.<br>
<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The reality is that standing up an HA Proxy Keystone multinode<br>
environment is going to be pretty extensive amount of work. And when<br>
things fail, digging out why, is kind of hard. However it feels like<br>
most of the interesting edges can be tested well at a lower level. And<br>
is at least worth getting those sorted before biting off the bigger thing.<br>
<span></span></blockquote><div><br></div><div>++ 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.<br><br></div><div>--Morgan <br></div></div></div></div>