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. I wonder if one could merge UUID and Fernet into a provider which handles this transition gracefully: if self._fernet_keys: return self._issue_fernet_token() else: return self._issue_uuid_token() And in the validation, do the same, but also with an eye toward keeping the UUID tokens alive: if self._fernet_keys: try: self._validate_fernet_token() except InvalidFernetFormatting: self._validate_uuid_token() else: self._validate_uuid_token() So that while one is rolling out new keystone nodes and syncing fernet keys, all tokens issued would validated properly, with minimal extra cost to support both (basically just a number of UUID tokens will need to be parsed twice, once as Fernet, and once as UUID). Thoughts? I think doing this would make changing the default fairly uncontroversial. __________________________________________________________________________ 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