Open Stack

On 05/03/2016 09:55 AM, Clint Byrum wrote:
> Excerpts from Steve Martinelli's message of 2016-05-02 19:56:15 -0700:
>> 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).
>>
> Assume all users are using defaults.
>
>> 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
>>
>
> Right, I responded there, but just to be clear, this is not about
> _operators_ being inconvenienced, it is about _users_.
>
>> 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.
>>
> Great! They are supremely efficient and I love that we're moving
> forward. However, users really do not care about something that just
> makes the operator's life easier if it causes all of their stuff to blow
> up in non-deterministic ways (since their new jobs won't have that fail,
> it will be a really fun day in the debug chair).
>
>>>
>>>> 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.
>>
> You say "on the fly" I say "when the operator has configured things
> fully".
>
> Perhaps we have different perspectives. How is accepting what we
> previously emitted and told the user would be valid sneaky or wrong?
> Sounds like common sense due diligence to me.
>
> Anyway, the idea could use a few kicks, and I think perhaps a better
> way to state what I'm thinking is this:
>
> 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.




>
> I fight for the users -- Tron
>
> __________________________________________________________________________
> 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