[openstack-dev] [keystone] Token providers and Fernet as the default

Clint Byrum clint at fewbar.com
Tue May 3 13:46:06 UTC 2016

Excerpts from Matt Fischer's message of 2016-05-02 16:39:02 -0700:
> On Mon, May 2, 2016 at 5:26 PM, Clint Byrum <clint at fewbar.com> wrote:
> > Hello! I enjoyed very much listening in on the default token provider
> > work session last week in Austin, so thanks everyone for participating
> > in that. I did not speak up then, because I wasn't really sure of this
> > idea that has been bouncing around in my head, but now I think it's the
> > case and we should consider this.
> >
> > Right now, Keystones without fernet keys, are issuing UUID tokens. These
> > tokens will be in the database, and valid, for however long the token
> > TTL is.
> >
> > The moment that one changes the configuration, keystone will start
> > rejecting these tokens. This will cause disruption, and I don't think
> > that is fair to the users who will likely be shown new bugs in their
> > code at a very unexpected moment.
> >
> This will reduce the interruption and will also as you said possibly catch
> bugs. We had bugs in some custom python code that didn't get a new token
> when the keystone server returned certain code, but we found all those in
> our dev environment.
> From an operational POV, I can't imagine that any operators will go to work
> one day and find out that they have a new token provider because of a new
> default. Wouldn't the settings in keystone.conf be under some kind of
> config management? I don't know what distros do with new defaults however,
> maybe that would be the surprise?

"Production defaults" is something we used to mention a lot. One would
hope you can run a very nice Keystone with only the required settings
such as database connection details.

Agreed that upgrades will be conscious decisions by operators, no doubt!

However, the operator is not the one who gets the surprise. It is the
user who doesn't expect their tokens to be invalidated until their TTL
is up. The cloud changes when the operator decides it changes. And if
that is in the middle of something important, the operator has just
induced unnecessary complication on the user.

More information about the OpenStack-dev mailing list