Skip to content

interpretation.adoc

Latest commit

 

History

History
134 lines (97 loc) · 4.37 KB

interpretation.adoc

File metadata and controls

134 lines (97 loc) · 4.37 KB
Raw

chrisomatic Schema Interpretation

This document describes how chrisomatic interprets a configuration file.

General Behavior

chrisomatic operates additively, meaning that it will only create data.

Default Resolution

The schema is flexible and uses defaults where values are not specified.

Compute Resource Creation

name is a required key of a compute_resource[*]. The other fields (url, username, password, description, innetwork) are optional if the compute resource already exists.

Currently, chrisomatic has the ability to create new compute resources. It cannot modify an existing compute resource.

Compute Resources of a Plugin

If compute_resource is not given for a cube.plugin, by default it will be registered to all known compute environments in cube.compute_resource.

on:
  cube_url: http://localhost:8000/api/v1/
  chris_superuser:
    username: chris
    password: chris1234

cube:
  compute_resource:
    - name: moc
      url: https://example.com/api/v1/
      username: fake
      password: fake1234
      description: Mass Open Cloud
    - name: hpc
      url: https://example.com/api/v1/
      username: fake
      password: fake1234
      description: High-performance computing cluster

  plugins:
    - name: pl-in-development
      dock_image: "localhost:5000/fnndsc/pl-indevelopment:latest"

In the example above, the plugin pl-in-development will be registered to all specified compute environments, moc and hpc.

Plugin String Resolution

If a plugin is a string, it will be resolved by this procedure:

First, if plugin is a container image present in the host’s docker daemon, plugin is interpreted as dock_image.

Else, plugin will be interpreted based on patterns, matching as these fields in this order:

Plugin Registration Strategy

If a Plugin is not registered to its compute environments, chrisomatic will attempt to do the following:

  1. Search for the plugin in the list of public CUBE instances, in the specified order. (default: ["https://cube.chrisproject.org/api/v1/"])

  2. Attempt to upload the plugin to CUBE.

Searching public CUBE instances can be disabled (i.e. force upload to local store):

on:
  cube_url: http://localhost:8000/api/v1/
  chris_superuser:
    username: chris
    password: chris1234
  public_store:

Plugin JSON Description Strategy

Most ChRIS plugins are created from either cookiecutter-chrisapp, or can be described by the chris_plugin_info tool.

chrisomatic will try to produce the plugin JSON representation by executing the plugin's dock_image as a container. It will try these commands, and if one doesn’t work, it tries the next:

  1. chris_plugin_info

  2. {{CMD}} --json, where {{CMD}} is the CMD set by Dockerfile

Plugin Store Owner

When a plugin needs to be uploaded to the local store first, and cube.plugins[*].owner is not specified, the first user listed in chris_store.users will own the uploaded plugin.

Error Handling

Errors which can be expected are handled by repeating the HTTP request after a delay. These errors include:

Some errors are irrecoverable, such as superuser creation.

In case of errors it’s safe to rerun chrisomatic. If the error was incidental, the rerun will be successful.