Open Stack

Comments inline...

On Mon, May 2, 2016 at 7:39 PM, Matt Fischer <matt at mattfischer.com> wrote:

> 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?
>

With respect to upgrades, assuming we default to Fernet tokens in the
Newton release, it's only an issue if the the deployer has no token format
specified (since it defaulted to UUID pre-Newton), and relied on the
default after the upgrade (since it'll switches to Fernet in Newton).

I'm glad Matt outlines his reasoning above since that is nearly exactly
what Jesse Keating said at the Fernet token work session we had in Austin.
The straw man we come up with of a deployer that just upgrades without
checking then config files is just that, a straw man. Upgrades are well
planned and thought out before being performed. None of the operators in
the room saw this as an issue. We opened a bug to prevent keystone from
starting if fernet setup had not been run, and Fernet is the
selected/defaulted token provider option:
https://bugs.launchpad.net/keystone/+bug/1576315

For all new installations, deploying your cloud will now have two extra
steps, running "keystone-manage fernet_setup" and "keystone-manage
fernet_rotate". We will update the install guide docs accordingly.

With all that said, we do intend to default to Fernet tokens for the Newton
release.


>
>
>>
>> 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()
>>
>
This just seems sneaky/wrong to me. I'd rather see a failure here than
switch token formats on the fly.

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/204e1e86/attachment.html>