Hi Matt! I didn't try to use Liberty tokens in Mitaka, but then I'll try to minimize the upgrade window.
Br, György > -----Original Message----- > From: Matt Fischer [mailto:[email protected]] > Sent: 2016 április 14, csütörtök 15:55 > To: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Subject: Re: [openstack-dev] [keystone]Liberty->Mitaka upgrade: is it > possible without downtime? > > 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" > <[email protected] > <mailto:[email protected]> > 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 <http://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- > [email protected]?subject:unsubscribe <http://OpenStack-dev- > [email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
