(Deprecated) Adding new executable to DMOD

Docker

A docker container is required for DMOD to launch the executable. For application directly supported by DMOD, these can be placed in docker/main/<application>/Dockerfile. If the application has specific dependencies, it is preferred to build and/or install these in an intermediate container, typically under docker/main/<application>/deps.

Either this intermediate container or the application container should start from the base container definition which establishes some simple environment configuration. This isn't strictly mandatory, but is encouraged.

Parallel application using MPI

#TODO create independent MPI build layer

#TODO document the use of that layer here

#TODO Document the required entrypoint components (i.e. run_model.sh)

Batch Jobs

For batch like jobs that do not require parallel communication, the container does not need to build from the parallel layer, and the entrypoint only needs to execute the application and forward any required dynamic args from the shell args $1 $2 $3 ect.

Request Handling

The following files should be edited to add a new App.

python/lib/communication/dmod/communication/maas_request.py

Any model supported by DMOD must have associated MaaSRequest and MaaSRequestResponse subclasses defined. I.e. class AppRequest(MaaSRequest): and class AppRequestResponse(MaaSRequestResponse):

#TODO document required cls attributes and factory methods needed for minimal implementation. #TODO document test coverage for new message types

These may need to be added to the package's __ini__.py in the from maas_request import ... section.

python/lib/communication/dmod/python/lib/communicaiton/dmod/message.py

A new enum entry should be added to the MessageEventType for the new App, i.e. APP_MAAS_REQUEST = <unique_int>`.

python/lib/communication/dmod/python/lib/communicaiton/dmod/client.py

Needs to import the new request subclasses defined in maas_request.py. Then in the function _run_validation(message: Union[MaaSRequest, MaaSRequestResponse]):, the message parameter should be checked against these types and proper validation called for the determined type.

python/lib/communication/dmod/python/lib/communicaiton/dmod/schemas/

A json schema to validate the app request is required as app.schema.json Also, in this directory you must add the app to request.schema.json by adding the App name to the model: propertyNames: enum[...] list, reference the app.schema.json in the properties: "App": key, and extend the "oneOf" list to include the App name as one of the possible required entries.

docker/main/schedulerservice/image_and_domain.yaml

Finally, some runtime information must be provided for DMOD to properly execute the correct application image. A mapping exists in image_and_domain.yaml that DMOD uses to manage this. You will need to add an entry here for you app. Note that the model_name attribute of the AppRequest class must match this key (and is case sensitive). An example entry in image_and_domain.yaml:

app:
  version:
    latest: '127.0.0.1:5000/app:latest'
    1: '127.0.0.1:5000/app:v1'
  domains:
    input-domain:
      local: './input-domain'
      run: './app/data'

The version map allows multiple versions of the application container to be selected based on the request's version attribute. The values of the version keys are the image tag in the DMOD registry corresponding the the application version to use with that key.

The domain key maps data available on the DMOD hosts in the local directory and DMOD will mount that to the container run directory before executing the application.

A request contains a domain attribute that is used as a key in this map to instruct DMOD which data to mount to run a given domain.