CloudMan Default/Public Bucket

Creating a new bucket is the fastest way to customize CloudMan, in fact cluster buckets are effectively this.

The key files inside a CloudMan default bucket, as detailed in CloudMan Architecture, are:

  • cm_boot.py
  • cm.tar.gz
  • snaps.yaml

The bucket often will also contain tarball archives of storage snapshots referred to by snaps.yaml, as well as configuration files to be used by tools (such as Galaxy, suffixed by “.cloud”).

cm_boot.py and cm.tar.gz can be sourced from the CloudMan repository (cm_boot.py just copied from the repository, cm.tar.gz produced by making a tarball of the repository), or if setting up a bucket on a cloud that already has one, by copying from an existing bucket. This is probably best if not working on an Amazon cloud, as sometimes modifications are made to allow CloudMan to function.

The snaps.yaml file has a relatively self-explanatory structure, with a basic example using only volume-snapshots in the CloudMan repository. A slightly more complex example is the default NeCTAR CloudMan bucket, which has examples of using volume-snapshots, tarball archives and GlusterFS network mounts. NFS and S3FS are also supported.

CloudMan Machine Image & GalaxyFS

The CloudMan Machine Image and GalaxyFS are unlikely to need to be built, unless there is a major change required, as was the case here, due to compatibility issues and an unpcoming new release of the GVL machine image we wanted to be compatible with. The process is documented in the containing Ansible playbook repo, as well as on the Galaxy Wiki.

Some modifications were made to the playbooks, these can be found in this forked repository, but also are in the process of being submitted upstream.