[openstack-dev] [Keystone] State of Fernet tokens
Morgan Fainberg
morgan.fainberg at gmail.com
Thu Feb 25 06:16:28 UTC 2016
On Wed, Feb 24, 2016 at 9:27 PM, Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:
>
>
> On Wed, Feb 24, 2016 at 8:50 PM, Adam Young <ayoung at redhat.com> wrote:
>
>> A lot of people seem to be counting on Fernet tokens, so I figured I'd
>> give a quick update.
>>
>> Back in December, I made a quick check to see what would happen if we
>> swapped Fernet in as the default token provider. A bunch of tests fails.
>> Lance Bragstad and Raildo Mascena took that and ran with it.
>>
>> As of tonight, there are 18 Failed test. 4 are due to trust tokens on
>> V2. we need to explicitly prevent trust execution for the V2 API, as the
>> rules are not being enforced. We sent up a warning about this before, but
>> let me make it explicit; V2 Trust support is being yanked due to the need
>> to make Fernet work.
>>
>> There are also some strange things going on with revocation events. Since
>> token revocations are only going to be handled via the revocation event API
>> (not revocation list) we need to get this right.
>>
>> Here is the complete list of failing tests right now:
>>
>>
>> These three are the trust tests I described above.
>>
>> {0}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_tokens_for_user_invalidates_tokens_from_trust
>> [0.420011s] ... FAILED
>> {0}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_token_from_trust_cant_get_another_token
>> [0.443193s] ... FAILED
>> {1}
>> keystone.tests.unit.test_auth.AuthWithTrust.test_delete_trust_revokes_token
>> [0.465307s] ... FAILED
>>
>>
>> Something seems to be strange with Cache invalidation. They all deal
>> with token deletion, which is handled by Revocation Events now.
>> But this seems to be a test problem, not with the main code.
>>
>> {5}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_unscoped_token
>> [0.082660s] ... FAILED
>> {4}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user
>> [0.085062s] ... FAILED
>> {3}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
>> [0.106043s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_id
>> [0.081628s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user
>> [0.244603s] ... FAILED
>> {1}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
>> [0.237667s] ... FAILED
>> {6}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_unscoped_token
>> [0.278852s] ... FAILED
>> {0}
>> keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_id
>> [0.254170s] ... FAILED
>>
>>
> All of these cache validation tests are failing for two distinct reasons:
>
> 1) the Fernet token key repository fixture is not being used for the
> classes. Add in the use of the key_repository fixture and the first failure
> will go away
>
> 2) The test is insanely synthetic and doesn't actually create data in the
> identity or assignment backends. These tests need to be real test cases not
> relying on the fact that the token backend contains the validated dataset.
> This basically comes down to doing the load_fixtures() call and making sure
> to use "real" project_id/user_id combinations.
>
>
Latest patchset resolves issues with cache invalidation
> {5}
>> keystone.tests.unit.test_v3_assignment.AssignmentInheritanceTestCase.test_crud_inherited_and_direct_assignment_on_projects
>> [1.390265s] ... FAILED
>> {3}
>> keystone.tests.unit.test_no_admin_token_auth.TestNoAdminTokenAuth.test_request_no_admin_token_auth
>> [0.111520s] ... FAILED
>>
>> Since the revocation list is not going to be used with Fernet, I am not
>> too worried about these. I think these tests can be changed to use PKI
>> tokens for now.
>>
>>
> Skip the revocation_list tests for Fernet absolutely.
>
>
Latest patchset skips revocation_list get attempts with Fernet.
>
>> {2} keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_md5
>> [2.025202s] ... FAILED
>> {2}
>> keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_sha256
>> [1.650198s] ... FAILED
>> {6}
>> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_audit_id_only_token
>> [1.024048s] ... FAILED
>> {5}
>> keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_ids_token
>> [1.091590s] ... FAILED
>>
>> And this one? Passed when I ran it directly. Looks like a bad test
>> setup.
>> {3}
>> keystone.tests.unit.test_v3_filters.IdentityTestListLimitCase.test_list_users_filtered_by_funny_name
>> [2.169297s] ... FAILED
>>
>>
>> Review is here:
>> https://review.openstack.org/#/c/258650
>>
>> __________________________________________________________________________
>> 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/20160224/c1217b4f/attachment.html>
More information about the OpenStack-dev
mailing list