<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 2, 2016 at 5:26 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello! I enjoyed very much listening in on the default token provider<br>
work session last week in Austin, so thanks everyone for participating<br>
in that. I did not speak up then, because I wasn't really sure of this<br>
idea that has been bouncing around in my head, but now I think it's the<br>
case and we should consider this.<br>
<br>
Right now, Keystones without fernet keys, are issuing UUID tokens. These<br>
tokens will be in the database, and valid, for however long the token<br>
TTL is.<br>
<br>
The moment that one changes the configuration, keystone will start<br>
rejecting these tokens. This will cause disruption, and I don't think<br>
that is fair to the users who will likely be shown new bugs in their<br>
code at a very unexpected moment.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I wonder if one could merge UUID and Fernet into a provider which<br>
handles this transition gracefully:<br>
<br>
if self._fernet_keys:<br>
  return self._issue_fernet_token()<br>
else:<br>
  return self._issue_uuid_token()<br>
<br>
And in the validation, do the same, but also with an eye toward keeping<br>
the UUID tokens alive:<br>
<br>
if self._fernet_keys:<br>
  try:<br>
    self._validate_fernet_token()<br>
  except InvalidFernetFormatting:<br>
    self._validate_uuid_token()<br>
else:<br>
  self._validate_uuid_token()<br>
<br>
So that while one is rolling out new keystone nodes and syncing fernet<br>
keys, all tokens issued would validated properly, with minimal extra<br>
cost to support both (basically just a number of UUID tokens will need<br>
to be parsed twice, once as Fernet, and once as UUID).<br>
<br>
Thoughts? I think doing this would make changing the default fairly<br>
uncontroversial.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>