Bug #9900

[Crunch2] [API] Add ephemeral "run token" for running containers

Added by Tom Clegg about 4 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
-
Category:
Crunch
Target version:
-
Start date:
08/31/2016
Due date:
% Done:

0%

Estimated time:
Story points:
-
Release:
Release relationship:
Auto

Description

Background

Currently it is possible for a container to be locked by two dispatch processes at once (see #9898).

Also, we want to avoid passing a long-lived auth token to compute nodes.

Resolution

Add a "run_auth_uuid" column to the containers table.
  • When state changes to Locked (i.e., during the "lock" action) generate a new token and store its UUID here.
  • When state changes to Queued, Complete, or Cancelled, invalidate the token and set this attribute to nil.
  • Include the token in the response to the "lock" API.
  • Do not include the token in any other API response.

The new token should have its scope restricted to /arvados/v1/containers/ and should be permitted to update the container (currently, only the locked_by_uuid token can update a locked container).

The token indicated by locked_by_uuid should still be permitted to unlock the container, but not perform other updates.

Update crunch-dispatch-* to pass the new token (instead of its own dispatch token) to crunch-run.


Related issues

Related to Arvados - Bug #9898: [Crunch2] [API] Add explicit container lock/unlock APIs to prevent dispatch racesResolved08/31/2016

Related to Arvados - Feature #8128: [Crunch2] API support for crunch-dispatchResolved04/28/2016

Copied from Arvados - Story #9328: [Crunch2] Prevent dispatch racesClosed

History

#1 Updated by Tom Clegg about 3 years ago

  • Status changed from New to Resolved

Resolved in #8128 with the auth_uuid column, except that it doesn't limit scope.

Also available in: Atom PDF