On Fri, Apr 15, 2016 at 8:04 PM, Adam Young <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. > I exist to beta test for you! > > 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. > Which review removes this, the one above? > > 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. > Wouldn't devstack handle the same way it might call keystone manage bootstrap or db_sync? Devstack could just call fernet_setup if that's the configured provider? Also I know that there is a session on this at the summit too, but for me, I want Fernet validation to be faster. I know work is underway for this in Newton, but I'd consider adding it to the to-do pile.
__________________________________________________________________________ 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
