On 04/18/2016 02:10 PM, Matt Fischer wrote:
Thanks Brant,
I will missing that distinction.
On Mon, Apr 18, 2016 at 9:43 AM, Brant Knudson <b...@acm.org
<mailto:b...@acm.org>> wrote:
On Mon, Apr 18, 2016 at 10:20 AM, Matt Fischer
<m...@mattfischer.com <mailto:m...@mattfischer.com>> wrote:
On Mon, Apr 18, 2016 at 8:29 AM, Brant Knudson <b...@acm.org
<mailto:b...@acm.org>> wrote:
On Fri, Apr 15, 2016 at 9:04 PM, Adam Young
<ayo...@redhat.com <mailto:ayo...@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.
My thought was to have this as a temporary fix as the default changes.
Once we settle in to Fernet, we can swap to "only Fernet if Fernet"
There is no reason Devstack can't read the config option from Keystone,
but that is a larger change than I want to make for this.
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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
