Open Stack

Unfortunately Keystone does not handle database upgrades like nova. and
they do tend to be disruptive. I have not tried Liberty to mitaka  myself,
but have you tried to validate a token granted on a mitaka node against the
liberty one?  If you are lucky the other nodes will still be able to
validate tokens during the upgrade. Even if other API calls fail this is
slightly less disruptive. What I would do is shut down your entire cluster
except for one node an upgrade that node first. If you find that other
nodes can still validate tokens, leave two up, so that the upgrade restart
doesn't cause a blip. Then upgrade the second node as quickly as possible.
I'd also strongly recommend a db backup before you start.

We did this last week from an early liberty commit to stable and had
incompatible db changes and a token format change and only had a brief
keystone outage.
On Apr 14, 2016 7:39 AM, "Gyorgy Szombathelyi" <
gyorgy.szombathelyi at doclerholding.com> wrote:

> Hi!
>
> I just experimenting with upgrading Liberty to Mitaka, and hit an issue:
> In Mitaka, the user table doesn't have 'name' field, so running mixed
> versions of Keystone could result in:
>
> Unknown column 'user.name' in 'field list'
>
> in some operation when the DB is already upgraded to Mitaka, but some
> keystone instances in a HA setup are still Liberty.
>
> Is this change is intentional? Should I ignore the problem and just
> upgrade all instances as fast as possible? Or I just overlooked something?
>
> Br,
> György
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20160414/9eea08cf/attachment.html>