<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 9, 2016 at 7:19 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 03/09/2016 01:11 AM, Tim Bell wrote:<br>
</div>
<blockquote type="cite">
<div>
<div>
<div><br>
</div>
</div>
</div>
<span>
<div style="font-family:Calibri;font-size:12pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Matt Fischer <<a href="mailto:matt@mattfischer.com" target="_blank"></a><a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack
Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank"></a><a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday 8 March
2016 at 20:35<br>
<span style="font-weight:bold">To: </span>"OpenStack
Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank"></a><a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[openstack-dev] [keystone] Using multiple token formats in a
one openstack cloud<br>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">I don't think your example is right: "<span style="font-size:12.8px">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.</span>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">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.</span></div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Tim</div>
</blockquote>
<br></span>
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. <br></div></blockquote><div><br></div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>You go back later and remove all the junk you had to do for UUIDs like cronjobs.</div><div><br></div><div>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. </div><div><br></div><div>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.</div></div></div></div>