Story #9186

[API] Test client impact of async_permissions_update=True

Added by Brett Smith over 4 years ago. Updated over 3 years ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
Story points:


One thing we know is likely to break is that when you create a new project, you won't be able to put things in that project, or even view it, until the permissions update finishes.

Deploy an API server with async_permissions_update=True and try to use it "normally" and see what clients break:

  • arv-put
  • arv-get
  • arv-keepdocker
  • arv-mount
  • arv-run-pipeline-instance
  • Workbench: Create new projects; upload data to them; run pipeline instances in them

Note that the API server should be preloaded with some data to make for an interesting test case. If the database is nearly empty, permissions updates will finish very quickly, and testing might reveal fewer issues than would occur at scale. Consider having at least 1,000 projects, and maybe a bunch of simple collections (with duplicated data) inside them.

Document the results here. The goal of this story is to determine what further development would be required to make asynchronous permissions updates viable in prodcution.

Related issues

Related to Arvados - Story #9502: [API] Update permissions cache as needed after select writesResolved06/28/2016

Follows (1 day) Arvados - Story #8886: [API] Do not block individual API queries on rebuilding the permissions graphResolved04/13/2016


#1 Updated by Tom Clegg over 3 years ago

  • Status changed from New to Closed

Obsoleted by current implementation of permission checks.

Also available in: Atom PDF