This document describes how chrisomatic
interprets a configuration file.
The schema is flexible and uses defaults where values are not specified.
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.
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
.
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:
-
peer CUBE plugin URL, e.g.
https://cube.chrisproject.org/api/v1/plugins/45/
-
dock_image
, e.g.docker.io/fnndsc/pl-simpledsapp:1.2.3
-
plugin name, e.g.
pl-simpledsapp
If a Plugin is not registered to
its compute environments,
chrisomatic
will attempt to do the following:
-
Search for the plugin in the list of public CUBE instances, in the specified order. (default:
["https://cube.chrisproject.org/api/v1/"]
) -
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:
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:
-
chris_plugin_info
-
{{CMD}} --json
, where{{CMD}}
is theCMD
set byDockerfile
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.
Errors which can be expected are handled by repeating the HTTP request after a delay. These errors include:
-
server disconnect
-
CUBE 400 errors: see FNNDSC/ChRIS_ultron_backEnd#366
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.