Open Stack

On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer <matt at mattfischer.com> wrote:

> On Mon, Apr 18, 2016 at 8:29 AM, Brant Knudson <blk at acm.org> wrote:
>
>>
>>
>> On Fri, Apr 15, 2016 at 9:04 PM, Adam Young <ayoung at redhat.com> wrote:
>>
>>> We all want Fernet to be a reality.  We ain't there yet (Except for
>>> mfish who has no patience) but we are getting closer.  The goal is to get
>>> Fernet as the default token provider as soon as possible. The review to do
>>> this has uncovered a few details that need to be fixed before we can do
>>> this.
>>>
>>> Trusts for V2 tokens were not working correctly.  Relatively easy fix.
>>> https://review.openstack.org/#/c/278693/ Patch is still failing on
>>> Python 3.  The tests are kindof racy due to the revocation event 1 second
>>> granularity.  Some of the tests here have A sleep (1) in them still, but
>>> all should be using the time control aspect of the unit test fixtures.
>>>
>>> Some of the tests also use the same user to validate a token as that
>>> have, for example, a role unassigned.  These expose a problem that the
>>> revocation events are catching too many tokens, some of which should not be
>>> treated as revoked.
>>>
>>> Also, some of the logic for revocation checking has to change. Before,
>>> if a user had two roles, and had one removed, the token would be revoked.
>>> Now, however, the token will validate successful, but the response will
>>> only have the single assigned role in it.
>>>
>>>
>>> Python 3 tests are failing because the Fernet formatter is insisting
>>> that all project-ids be valid UUIDs, but some of the old tests have "FOO"
>>> and "BAR" as ids.  These either need to be converted to UUIDS, or the
>>> formatter needs to be more forgiving.
>>>
>>> Caching of token validations was messing with revocation checking.
>>> Tokens that were valid once were being reported as always valid. Thus, the
>>> current review  removes all caching on token validations, a change we
>>> cannot maintain.  Once all the test are successfully passing, we will
>>> re-introduce the cache, and be far more aggressive about cache invalidation.
>>>
>>> Tempest tests are currently failing due to Devstack not properly
>>> identifying Fernet as the default token provider, and creating the Fernet
>>> key repository.  I'm tempted to just force devstack to always create the
>>> directory, as a user would need it if they ever switched the token provider
>>> post launch anyway.
>>>
>>>
>> There's a review to change devstack to default to fernet:
>> https://review.openstack.org/#/c/195780/ . This was mostly to show that
>> tempest still passes with fernet configured. It uncovered a couple of test
>> issues (similar in nature to the revocation checking issues mentioned in
>> the original note) that have since been fixed.
>>
>> We'd prefer to not have devstack overriding config options and instead
>> use keystone's defaults. The problem is if fernet is the default in
>> keystone then it won't work out of the box since the key database won't
>> exist. One option that I think we should investigate is to have keystone
>> create the key database on startup if it doesn't exist.
>>
>> - Brant
>>
>>
>
> I'm not a devstack user, but as I mentioned before, I assume devstack
> called keystone-manage db_sync? Why couldn't it also call keystone-manage
> fernet_setup?
>
>
When you tell devstack that it's using fernet then it does keystone-manage
fernet_setup. When you tell devstack to use the default, it doesn't
fernet_setup because for now it thinks the default is UUID and doesn't
require keys. One way to have devstack work when fernet is the default is
to have devstack always do keystone-manage fernet_setup.

Really what we want to do is have devstack work like other deployment
methods. We can reasonably expect featureful deployers like puppet to
keystone-manage fernet_setup in the course of setting up keystone. There's
more basic deployers like RPMs or debs that in the past have said they like
the defaults to "just work" (like UUID tokens) and not require extra
commands.

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160418/3ed3be4a/attachment.html>