Excerpts from Adam Young's message of 2016-05-03 07:21:52 -0700: > On 05/03/2016 09:55 AM, Clint Byrum wrote: > > When the operator has configured a new token format to emit, they should > > also be able to allow any previously emitted formats to be validated to > > allow users a smooth transition to the new format. We can then make the > > default behavior for one release cycle to emit Fernet, and honor both > > Fernet and UUID. > > > > Perhaps ignore the other bit that I put in there about switching formats > > just because you have fernet keys. Let's say the new pseudo code only > > happens in validation: > > > > try: > > self._validate_fernet_token() > > except NotAFernetToken: > > self._validate_uuid_token() > > I was actually thinking of a different migration strategy, exactly the > opposite: for a while, run with the uuid tokens, but store the Fernet > body. After while, switch from validating the uuid token body to the > stored Fernet. Finally, switch to validating the Fernet token from the > request. That way, we always have only one token provider, and the > migration can happen step by step. > > It will not help someone that migrates from Icehouse to Ocata. Then > again, the dual plan you laid out above will not either; at some point, > people will have to dump the token table to make major migrations. >
Your plan has a nice aspect that it allows validating Fernet tokens on UUID-configured nodes too, which means operators don't have to be careful to update all nodes at one time. So I think what you describe above is an even better plan. Either way, the point is to avoid an immediate mass token invalidation event on change of provider. __________________________________________________________________________ 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
