Skip to main content

CWL runner for Kubernetes

Project description

Calrissian

CWL on Kubernetes

Build Workflow

Overview

Calrissian is a CWL implementation designed to run inside a Kubernetes cluster. Its goal is to be highly efficient and scalable, taking advantage of high capacity clusters to run many steps in parallel.

Cluster Requirements

Calrissian requires a Kubernetes or Openshift/OKD cluster, configured to provision PersistentVolumes with the ReadWriteMany access mode. Kubernetes installers and cloud providers don't usually include this type of storage, so it may require additional configuration.

Calrissian has been tested with NFS using the nfs-client-provisioner and with GlusterFS using OKD Containerized GlusterFS. Many cloud providers have an NFS offering, which integrates easily using the nfs-client-provisioner.

Scalability / Resource Requirements

Calrissian is designed to issue tasks in parallel if they are independent, and thanks to Kubernetes, should be able to run very large parallel workloads.

When running calrissian, you must provide a limit the the number of CPU cores (--max-cores) and RAM megabytes (--max-ram) to use concurrently. Calrissian will use CWL ResourceRequirements to track usage and stay within the limits provided. We highly recommend using accurate ResourceRequirements in your workloads, so that they can be scheduled efficiently and are less likely to be terminated or refused by the cluster.

calrissian parameters can be provided via a JSON configuration file either stored under ~/.calrissian/default.json or provided via the --conf option.

Below an example of such a file:

{
    "max_ram": "16G",
    "max_cores": "10",
    "outdir": "/calrissian",
    "tmpdir_prefix": "/calrissian/tmp"
}

CWL Conformance

Calrissian leverages cwltool heavily and most conformance tests for CWL v1.0. Please see conformance for further details and processes.

To view open issues related to conformance, see the conformance label on the issue tracker.

Setup

Please see examples for installation and setup instructions.

Environment Variables

Calrissian's behaviors can be customized by setting the following environment variables in the container specification.

Pod lifecycle

By default, pods for a job step will be deleted after termination

  • CALRISSIAN_DELETE_PODS: Default true. If false, job step pods will not be deleted.

Kubernetes API retries

When encountering a Kubernetes API exception, Calrissian uses a library to retry API calls with an exponential backoff. See the tenacity documentation for details.

  • RETRY_MULTIPLIER: Default 5. Unit for multiplying the exponent interval.
  • RETRY_MIN: Default 5. Minimum interval between retries.
  • RETRY_MAX: Default 1200. Maximum interval between retries.
  • RETRY_ATTEMPTS: Default 10. Max number of retries before giving up.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distributions

No source distribution files available for this release.See tutorial on generating distribution archives.

Built Distribution

calrissian-0.16.0-py2.py3-none-any.whl (30.7 kB view details)

Uploaded Python 2 Python 3

File details

Details for the file calrissian-0.16.0-py2.py3-none-any.whl.

File metadata

File hashes

Hashes for calrissian-0.16.0-py2.py3-none-any.whl
Algorithm Hash digest
SHA256 139c90a732336da9f7a9987cc94dffe5c4ed36552a15f9e530e1bd9b28bfb1c1
MD5 d11a6f79bf385375bd4fc7f5ff782311
BLAKE2b-256 023fa9890d00e42af4d5335bc6f5a136d3043f1ef36191b0044b1ebd4e546fff

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page