Open Stack

Thanks Brant,

I will missing that distinction.

On Mon, Apr 18, 2016 at 9:43 AM, Brant Knudson <blk at acm.org> wrote:

>
>
> 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
>
>
> __________________________________________________________________________
> 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/20160418/2e7f9fba/attachment.html>