Open Stack

On Wed, Mar 9, 2016 at 7:19 AM, Adam Young <ayoung at redhat.com> wrote:

> On 03/09/2016 01:11 AM, Tim Bell wrote:
>
>
> From: Matt Fischer < <matt at mattfischer.com>matt at mattfischer.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> <openstack-dev at lists.openstack.org>openstack-dev at lists.openstack.org>
> Date: Tuesday 8 March 2016 at 20:35
> To: "OpenStack Development Mailing List (not for usage questions)" <
> <openstack-dev at lists.openstack.org>openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [keystone] Using multiple token formats in a
> one openstack cloud
>
> I don't think your example is right: "PKI will validate that token
> without going to any keystone server". How would it track revoked tokens?
> I'm pretty sure that they still get validated, they are stored in the DB
> even.
>
> I also disagree that there are different use cases. Just switch to fernet
> and save yourself what's going to be weeks of pain with probably no
> improvement in anything with this idea.
>
>
> Is there any details on how to switch to Fernet for a running cloud ? I
> can see a migration path where the cloud is stopped, the token format
> changed and the cloud restarted.
>
> It seems more complex (and maybe insane, as Adam would say) to do this for
> a running cloud without disturbing the users of the cloud.
>
> Tim
>
>
> So, Fernet does not persist, UUID does.  I would guess that a transition
> plan would involve being able to fall back to a persisted UUID if the
> Fernet validation does not work.
>


When we did this we had a few disadvantages. We also upgraded Keystone to
liberty and switched to apache at the same time. This caused db migrations
and more work for puppet. Also as I mentioned the old kilo keystone
middleware can't figure out what to do when you switch token providers,
either restart services or wait for them to think that their tokens have
expired. Because of this we used ansible scripts to orchestrate the process
including db backups (standard when you upgrade a service for us).

Without this degree of difficulty, the transition should be pretty easy.
You setup the keys ahead of time, change the config file, and restart
keystone. The other services should figure it out. If not, you just do a
rolling restart with ansible of API services. Keystone is down for as long
as this takes and your API services are down until you can bounce them. We
maintain a "safe" list of services to restart (which we usually use for
Rabbit issues) and just ran through that list.

You go back later and remove all the junk you had to do for UUIDs like
cronjobs.

I would recommend testing a "failed" transition as well. We did this in our
lab and documented steps for the fallback process to minimize the risk in
production.

I'd be happy to share all my notes + ansible scripts but they were probably
overly cautious since it included an upgrade which meant DB migrations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160309/9af7d0bb/attachment.html>