Idea #6429
Updated by Tom Clegg over 8 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 with * Non-admin Access controls (e.g., users cannot modify Container records records) * Non-admin users Validations (e.g., container state cannot modify the container_uuid of a ContainerRequest, except by setting it change from Completed to null when state==Uncommitted. State changes Queued; repositories and validations * ContainerRequest state defaults to Uncommitted. * ContainerRequest state transition ∈ {Uncommitted→Committed, Committed→Final} -- any other transition causes an error. * ContainerRequest cannot inputs must be modified readable by anyone if state=Final. the submitter) * ContainerRequest cannot be modified if state=Committed -- except priority, container_uuid, and container_count_max. * Container state ∈ {Queued, Running, Cancelled, Failed, Complete}. * Container state transition ∈ {Queued→Running, Queued→Cancelled, Running→Cancelled, Running→Failed, Running→Complete} -- any other transition causes an error. * properties attribute must be a Hash, etc. (use existing patterns Locking mechanism for handling serialized attributes) Creating and stopping Container objects use by scheduler * When a ContainerRequest's Apply cascading effects of 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 Container exits, cancel all active ContainerRequests that it is Committed and has), update Container priority to the max priority of any ContainerRequest with the corresponding container_uuid. initiated * ** When a ContainerRequest cancels or changes priority to zero, cancels, and this leaves its a Container running but with priority=0, without any active requests, cancel the container. * When changing Container state away from Running, cancel all active ContainerRequests that were initiated by this Container (see requesting_container_uuid). container *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 Definition of one dispatcher running at a time. "minimal feature set" TBD. Possibilities: * Re-use an existing No container that meets the criteria of re-use: create 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. satisfy each ContainerRequest with @priority>0@. * API documentation. The feature doesn't work yet, so we don't need to advertise it. * No support for expires_at, filters, container_count_max (for now these must be null/empty) * validation of runtime_constraints, container_image, environment, cwd, etc. (but don't ignore them -- just reject submissions that specify anything but the one supported null/easy value for each respective feature)