<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 9:27 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Feb 24, 2016 at 8:50 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    A lot of people seem to be counting on Fernet tokens, so I figured
    I'd give a quick update.
    <br>
    <div style="font-family:-moz-fixed;font-size:12px" lang="x-unicode">
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      Here is the complete list of failing tests right now:
      <br>
      <br>
      <br>
      These  three are the trust tests I described above.
      <br>
      <br>
      {0}
      keystone.tests.unit.test_auth.AuthWithTrust.test_delete_tokens_for_user_invalidates_tokens_from_trust
      [0.420011s] ... FAILED
      <br>
      {0}
      keystone.tests.unit.test_auth.AuthWithTrust.test_token_from_trust_cant_get_another_token
      [0.443193s] ... FAILED
      <br>
      {1}
      keystone.tests.unit.test_auth.AuthWithTrust.test_delete_trust_revokes_token
      [0.465307s] ... FAILED
      <br>
      <br>
      <br>
      Something seems to be strange with Cache invalidation.  They all
      deal with token deletion, which is handled by Revocation Events
      now.
      <br>
      But this seems to be a test problem, not with the main code.<br>
      <br>
      {5}
      keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_unscoped_token
      [0.082660s] ... FAILED
      <br>
      {4}
      keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user
      [0.085062s] ... FAILED
      <br>
      {3}
      keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
      [0.106043s] ... FAILED
      <br>
      {1}
      keystone.tests.unit.test_backend_kvs.KvsTokenCacheInvalidation.test_delete_scoped_token_by_id
      [0.081628s] ... FAILED
      <br>
      {1}
      keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user
      [0.244603s] ... FAILED
      <br>
      {1}
      keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_user_and_tenant
      [0.237667s] ... FAILED
      <br>
      {6}
      keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_unscoped_token
      [0.278852s] ... FAILED
      <br>
      {0}
      keystone.tests.unit.test_backend_sql.SqlTokenCacheInvalidation.test_delete_scoped_token_by_id
      [0.254170s] ... FAILED
      <br>
      <br></div></div></blockquote><div><br></div></span><div>All of these cache validation tests are failing for two distinct reasons:<br><br></div><div>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<br><br></div><div>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. <br></div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>Latest patchset resolves issues with cache invalidation<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div style="font-family:-moz-fixed;font-size:12px" lang="x-unicode">
      {5}
      keystone.tests.unit.test_v3_assignment.AssignmentInheritanceTestCase.test_crud_inherited_and_direct_assignment_on_projects
      [1.390265s] ... FAILED
      <br>
      {3}
      keystone.tests.unit.test_no_admin_token_auth.TestNoAdminTokenAuth.test_request_no_admin_token_auth
      [0.111520s] ... FAILED
      <br>
      <br>
      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.
      <br>
      <br></div></div></blockquote><div><br></div></span><div>Skip the revocation_list tests for Fernet absolutely.<br></div><div> </div></div></div></div></blockquote><div><br></div><div>Latest patchset skips revocation_list get attempts with Fernet.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div text="#000000" bgcolor="#FFFFFF"><div style="font-family:-moz-fixed;font-size:12px" lang="x-unicode">
      <br>
      {2}
      keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_md5
      [2.025202s] ... FAILED
      <br>
      {2}
      keystone.tests.unit.test_v2.V2TestCase.test_fetch_revocation_list_sha256
      [1.650198s] ... FAILED
      <br>
      {6}
      keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_audit_id_only_token
      [1.024048s] ... FAILED
      <br>
      {5}
      keystone.tests.unit.test_v3_auth.TestFetchRevocationList.test_ids_token
      [1.091590s] ... FAILED
      <br>
      <br>
      And this one?  Passed when I ran it directly.  Looks like a bad
      test setup.
      <br>
      {3}
      keystone.tests.unit.test_v3_filters.IdentityTestListLimitCase.test_list_users_filtered_by_funny_name
      [2.169297s] ... FAILED
      <br>
      <br>
      <br>
      Review is here: <br>
      <a href="https://review.openstack.org/#/c/258650" target="_blank">https://review.openstack.org/#/c/258650</a><br>
    </div>
  </div>

<br></span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></div>