Skip to end of metadata
Go to start of metadata

Overview of "Define Execution Engine" Use Case

Add new type of process execution engine to the Integrated Observatory


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Application Developer, Integrated Observatory Operator
References  
Uses  
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios None
Technical Notes  
Lead Team CEI
Primary Service Execution Engine Catalog & Repository Services
Version 2.0
UC Priority 3
UC Status Mapped + Ready
UX Exposure PGM

Summary

This information summarizes the Use Case functionality.

Describe and integrate a new type of execution engine based on the base operational unit and the capability container. An example is Matlab or SQLstream, which are both execution engines with purpose-built application logic to consume work and produce higher level products. Provide an executable engine description and register it.

Assumptions

  • Defining an execution engine can be done during integration time or during operations
  • A registry for execution engines exists

Initial State

Execution engine has been developed using the standard Operational Unit/Deployable Type mechanisms.

Scenario for "Define Execution Engine" Use Case

  1. Application Developer provides entities required for an engine: base images, contextualization scripts, and packages
    1. Via operator console, script/API
    2. To the software component repository
  2. Application Developer creates execution engine launch descriptions
    1. Deployable Type description (specifies a VM)
    2. Configuration for Deployable Type
    3. metadata about the Execution Engine
  3. Application Developer registers the execution engine with the Integrated Observatory system.
    1. Via operator console, API: For standard execution engine types, this occurs via API during integration time
    2. Provide execution engine metadata: Owner, producer; Name, description; Version; Compatible list with other existing execution engines
    3. Access restrictions
    4. Registration in the resource registry and directory service
  4. Application Developer activates the execution engine for use (i.e., gives permission for it to be used)
    1. System Process Developer can now deploy a process or service on the newly available execution engine
    2. To run the Execution Engine, Integrated Observatory Operator creates an Elastic Processing Unit for the Execution Engine. (This is done by command line, most likely.) This EPU instance will create and destroy EE instances as needed, and as dictated by policy.
  5. (optional) Application Developer deactivates and decommissions the execution engine
    1. Elimination of operational engines before deactivation step is TBD

Final State

The execution engine can be instantiated.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.