On 03/09/2016 01:44 AM, Matt Fischer wrote:
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.
It requires a brief outage as you switch the provider over. We stopped
all but 1 node in the cluster then modified it, we did liberty +
fernet + apache all at the same time to avoid multiple restarts. As
for the other services, newer keystone middlewares will realize "hey
my token doesn't work anymore" and will get a new one. At the time we
did ours, this was not the case, so we bounced every service that uses
the middleware. All in all in was a brief outage, basically the length
of time to upgrade a few packages and restart a service on a single
node.. My opinion is that it was far less invasive than something like
upgrading neutron, but the APIs were down for a brief time.
Come to my talk in Austin and we'll cover it a bit more.
Captured it here. Please update with notes.
https://bugs.launchpad.net/keystone/+bug/1555137
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
