Information model and API
#
Model DefinitionA ModelDefinition can be used to define information about where an image is stored.
#
Model Definition objectThe information in ModelDefinition:
- Name(*) - image name
- Version(*) - the version tag of the initial version of the Docker image
- URI - exact location of the container (should be specified when location is external)
- Location(*) - allowed values :
ACR(Azure Container Registry) | External
- CreatedDate - created date of ModelDefinition
ModelDefinition with the same name can have multiple versions.
#
ModelModel is typically set up around a specific ModelDefinition, which defines the parameters and default values of resources to be used for running a container. These resources include CPU cores, GPU cores, memory and GPU SKU.
#
Model objectThe information in Model:
- Id - unique id
- Name(*)
- ModelId - string (MOD-00001)
- Description
- ModelDefinitionName, ModelDefinitionVersion - to assign model to a specific ModelDefinition
- Status - allowed values :
Draft | Active | Deprecated
- CPUCores, Memory, GPUCores - default values (can be overriden in Monitor)
- GPUSKU - Allowed value :
K80
- ConfigurableParameters - key value pairs of strings to indicate the name and value of the parameters of the container (can be overriden in Monitor)
- StaticParameters - key value pairs of strings to indicate the name and value of the parameters of the container (cannot be overriden in Monitor)
- ObjectOwner(*) - owner of Model
- Properties - additional properties
#
Populations and Population ItemsModel can have Populations and PopulationItems.
The user has the ability to specify where the Model can be applied on (which Population this Model is valid for). This means that it can be applied on different kind of asset data.
#
PopulationPopulation is used for grouping assets with the same type.
- Id - unique id
- Name(*)
- Description
- AssetType - allowed values :
Plant | MainSystem | Organization | Equipment
#
Population ItemPopulationItem is used to reference an asset in the system. PopulationItem is created using population id in headers.
- Id - unique id
- AssetReference(*)
- Id(*) - asset id
- Name - asset name
Since a population is a group of assets of the same type, the referenced asset in each population item should also be of that type.
#
MonitorMonitor can be created based on Model.
#
Monitor objectThe information in Monitor:
- Id - unique id
- Name(*)
- MonitorId - string (MON-00001)
- Model(*) - to assign Monitor to a specific Model
- Status - allowed values :
Draft | Active | Deprecated
- TriggerSchedule - CRON expression to schedule an execution for the container
- TriggerEvent
- CPUCores, Memory, GPUCores, GPUSKU - inherited values from linked Model
- Instructions
- ConfigurableParameters - the name and value of the parameters of the container inherited from linked Model
- ObjectOwner(*) - owner of Monitor
- Controllers - to specify different conditions for monitoring
- Name
- Conditions
- VariableName(*)
- Operator(*) - allowed values :
LessThan | LessThanOrEqual | GreaterThen | GreaterThanOrEqual | Equal
- comparisonValue(*) - float number
All of the inherited fields from the linked Model can be overriden in the Monitor.
There is also Duplication endpoint for Monitor. This duplicates the specified Monitor, including all of its Populations and PopulationItems.
POST /Monitors/{id}/Duplication
#
Populations and Population ItemsIn Monitor, there are Populations and PopulationItems that are inherited from the Model, but can be modified to suit for the specific Monitor. This allows the user to determine which assets the Monitor should be applied to.
The following endpoint is used to get the population items of all monitors:
GET /Monitors/PopulationItems
This endpoint has the monitorIds
, assetIds
and assetType
filters, and the assetType
is required when the assetIds
filter has value(s). This endpoint returns:
- Id - population item id
- Monitor
- Id - monitor id
- Name - monitor name
- Population
- Id - population id
- Name - population name
- AssetReference
- Id - asset id
- Name - asset name
- Type - type of asset (equipment, main system, plant, organization)
- Criticality - number in [0,100] range
- LastMonitorJobId - last executed MonitorJob id
#
Population Items within the MonitorWithin the Monitor, each population item has a 'Criticality' value that can be updated with every job execution. To track the most recent Monitor run, the 'LastMonitorJobId' is maintained.
- Id - unique id
- AssetReference(*)
- Id(*) - asset id
- Name - asset name
- Criticality - number in [0,100] range
- LastMonitorJobId - last executed MonitorJob id
When a level of Criticality is specified for a PopulationItem/asset, the user can see a corresponding color displayed next to it in the web.
- [0, 59] - green
- [60, 79] - yellow
- [80, 100] - red
#
Monitor JobAfter each Monitor trigger based on the trigger schedule, a new MonitorJob is created to track container execution. MonitorJob combines the static parameters from the Model with the configurable parameters from the Monitor as parameters, which are set as environmental variables. Parameters also contain associated monitor id(key: "monitorId") to enable getting corresponding Monitor with the use of monitor id in environmental variables list. The MonitorJob can also be executed by the user using the POST/MonitorJobs/Execution/{monitorId}
endpoint.
#
Monitor Job objectThe information in Monitor Job:
- Id - unique id
- Monitor
- ModelDefinitionName, ModelDefinitionVersion
- CreatedDate
- Status - job status. Values :
Unknown | Started | InProgress | Failed | Succeeded
- Parameters - combination of static and configurable parameters / environmental variables
- ErrorMessage - errors happened during execution
- Output - output inside batch account/ACI after container execution
- CompletedDate - completed date of execution
When a MonitorJob is created and the associated image is located in ACR, a new job will be executed in the DataProcessing domain. Once the job has finished executing, the details of the job (such as its status, error messages and output) will be set in the Monitor domain, inside the MonitorJob. If the container is located in an external resource, there is a PUT endpoint available for updating the MonitorJob's status.