Open Stack

If we were to write a uuid/fernet hybrid provider, it would only be
expected to support something like stable/liberty to stable/mitaka, right?
This is something that we could contribute to stackforge, too.

On Tue, May 3, 2016 at 9:21 AM, Adam Young <ayoung at redhat.com> wrote:

> 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
>>
>
>
> __________________________________________________________________________
> 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/20160503/0ff09f2b/attachment.html>