Idea #6429
Updated by Tom Clegg about 9 years ago
See [[Containers API]] and [[Crunch2 migration]]
For this initial implementation, focus on implementing and testing a minimal feature set establishing the life cycle of Container and ContainerRequest objects, thus enabling us to develop and test other Crunch2 components.
h3. Implementation notes
Implement validations/restrictions and methods at the model layer, not in controller methods.
h3. Tests
Access control
* Non-admin users cannot modify Container records
* Non-admin users cannot modify the container_uuid of a ContainerRequest, except by setting it to null when state==Uncommitted.
State changes and validations
* ContainerRequest state defaults to Uncommitted.
* ContainerRequest state transition ∈ {Uncommitted→Committed, Committed→Final} -- any other transition causes an error.
* ContainerRequest cannot be modified by anyone if state=Final.
* ContainerRequest cannot be modified if state=Committed -- except priority, container_uuid, and container_count_max.
* Container state ∈ {Queued, Running, Cancelled, -Failed,- Failed, Complete}.
* Container state transition ∈ {Queued→Running, Queued→Cancelled, Running→Cancelled, -Running→Failed,- Running→Failed, Running→Complete} -- any other transition causes an error.
* properties attribute must be a Hash, etc. (use existing patterns for handling serialized attributes)
Creating and stopping Container objects
* When a ContainerRequest's state changes from Uncommitted→Committed (regardless of priority), create a new Container populated with the relevant ContainerRequest attributes. Store the new Container's UUID as the ContainerRequest's container_uuid.
* When a ContainerRequest changes priority (which means it is Committed and has), update Container priority to the max priority of any ContainerRequest with the corresponding container_uuid.
* When a ContainerRequest cancels or changes priority to zero, and this leaves its Container running but with priority=0, cancel the container.
* When changing Container state away from Running, cancel all active ContainerRequests that were initiated by this Container (see requesting_container_uuid).
*Not* needed for this initial implementation:
* Locking mechanism for running containers. We will certainly need it for production, but it isn't included in this increment. For now we'll accept the limitations, like a maximum of one dispatcher running at a time.
* Re-use an existing container that meets the criteria of a ContainerRequest. For now every ContainerRequest that gets committed will result in a new Container being created.
* Check whether repositories and inputs are readable by the submitter.
* Dispatch/execute the containers that get created. For now all containers will just stay queued, because there is no component to dispatch them yet.
* API documentation. The feature doesn't work yet, so we don't need to advertise it.
* expires_at, filters, container_count_max (for now these must be null/empty)
* validation of runtime_constraints, container_image, environment, cwd, etc.