Allows to launch image instances on StratusLab cloud frontend. The image to be instantiated can be either Marketplace image ID or PDISK volume UUID.

Usage: stratus-run-instance [defaultOptions] image

image - Marketplace image ID or PDISK volume UUID

As a way of delivering context information to VM one can provide a set of key=value pairs via stratus-run-instance using the following parameters.

  --context-file=FILE   extra context file with one key=value per line
  --context=CONTEXT     extra context string (separate by #)

Example.

$ cat context.file 
var3=VAL3
VAR4=val4
$ stratus-run-instance --context="var1=VAL1"#"VAR2=val2" --context-file=context.file ... -vv | awk '/CONTEXT/,/]/'
CONTEXT = [
public_key = "...",
VAR4 = "val4",
var1 = "VAL1",
var3 = "VAL3",
VAR2 = "val2",
target = "hdd"
]
$ 

The variables will be provided to the cloud layer and will become available on VM under /mnt/stratuslab/context.sh.

my-VM-instance # cat /mnt/stratuslab/context.sh
...
VAR4="val4"
VAR1="VAL1"
VAR3="VAL3"
VAR2="val2"
...

 NB! Currently on VM all the variable names will be transformed into upper-case.

To get the variables available, one have to source the file

  
  source /mnt/stratuslab/context.sh
     or
  . /mnt/stratuslab/context.sh
  

As one can see /mnt/stratuslab/context.sh defines the variables following Bourne shell family shells specification.

 NB! Sourcing the file under C shell family shells will fail.

And the variables are shell variables (i.e. available locally for the current shell instance only) - not environment variables which can be inherited by forked subprocesses (i.e., not “export”-ed).

To workaround the problem on VM one can do the following.

CONTEXT_FILE=/mnt/stratuslab/context.sh
VARS=`cat $CONTEXT_FILE | egrep -e '^[a-zA-Z\-\_0-9]*=' | sed 's/=.*$//'`
for v in $VARS; do
  export $v
done

When providing SCRIPT_EXEC context variable (see Providing script to be launched at intialization) the above export is done automatically and the variables can be directly used from the script specified by SCRIPT_EXEC.

One can provide a simple script to be launched on VM during initialization process via SCRIPT_EXEC=“your script” variable.

stratus-run-instance \
  --context="abc=ABC"#"script_exec=wget -O /tmp/myprog.bootstrap http://<hostname>/myprog.bootstrap && chmod +x /tmp/myprog.bootstrap && /tmp/myprog.bootstrap" ...

In ”–quiet” mode prints out instance ID and assigned IP. In highest level of verbosity (-vvv) prints out all the operations the command performs: what endpoints are contacted to perform image meta-information lookup, the instance deployment template, etc.

stratus-run-instance --endpoint grnet.cloud.stratuslab.eu \
    -t m1.xlarge \
    --save --author-email john@example.com \
    --volatile-disk 2 \
    --notify "dev.rabbitmq.com,/,guest,guest,random_queue" \
    PvitUfM-uW2yWakWUNmd-TSPOiy

Launch one instance of type m1.xlarge (2 CPU, 1024 MB, 1024 MB) of an image identified by the image ID PvitUfM-uW2yWakWUNmd-TSPOiy (found in default Marketplace). Attach volatile disk of size 2GB. Save the instance as a new image when shutdown operation is called. (The volatile disk will not be saved.) On successful new image creation send email to john@example.com. Notify on each instance state change on the provided (AMQP) messaging endpoint.

Prints out details of active or failed instances belonging to the user. When run with -v more verbose information is printed, including failure details if present.

Usage: stratus-describe-instance [options] [vm-id]

[vm-id] - space separated list of VM IDs. Without the parameter [vm-id] the
command lists the available VMs belonging to the user (-u/--username).

If the Cloud site provides port address translation (PAT) and instances were started with request to perform PAT, the following options will display the assigned translation.

  --pat-enable          show port address translations
  --pat-service-host=HOST/IP
                        set the hostname/ip of port translation service
  --pat-gateway-host=HOST/IP
                        set the hostname/ip of port translation gateway

If you happen to have multiple accounts on different cloud endpoints by providing -m option (and preliminary setting “endpoints” parameter in user configuration file (see reference configuration file)) will display VMs running on the defined endpoints.

  -m                    Print state of virtual machines on multiple sites.
                        "endpoints" parameter should be set in user
                        configuration file.

Details of active or failed instances belonging to the user.

+

~ $ stratus-describe-instance -m -vvv
::: cloud.grnet.stratuslab.eu : konstan :::
id  state     vcpu memory    cpu% ip              name
::: cloud.lal.stratuslab.eu : konstan :::
<ProtocolError for xxxxx:*****@cloud.lal.stratuslab.eu:2634/pswd/xmlrpc: 401 Unauthorized>
::: onehost-5.lal.in2p3.fr : oneadmin :::
id  state     vcpu memory    cpu% ip              name
::: 213.157.30.133 : oneadmin :::
WARNIG: Could not get results in 5 sec
::: 62.217.120.135 : oneadmin :::
id  state     vcpu memory    cpu% ip              name
13  Failed    1    0         0    62.217.120.179  one-13
    Error executing image transfer script: Image sha1 checksum check failed.
::: 62.217.120.145 : test :::
id  state     vcpu memory    cpu% ip              name
4   Running   1    131072    1    62.217.120.172  one-4
5   Running   1    131072    1    62.217.120.173  one-5
~ $ 

Sends kill signal to user's active instances specified by IDs.

Usage: stratus-kill-instance [options] vm-id ...

No output.

~ $ stratus-kill-instance {34..40}
~ $

Kills instances in the range {34..40} if they belong to the user.

Sends shutdown signal to active instances specified by IDs. Instances should support ACPI. By default, if instance doesn't shutdown in 10 min it will be killed.

Usage: stratus-shutdown-instance [options] vm-id ...

No output.

~ $ stratus-shutdown-instance 101
~ $

Attempts a graceful shutdown of the specified instance (if it belongs to the user).

This command is useful with “stratus-run-instance –save”.

1. launch an instance of the base image via

  stratus-run-instance --save --author-email <email> <base-image ID>

2. ssh to the instance and apply required modifications

3. run

  stratus-shutdown-instance <instance ID>

4. user receives email with details on how to proceed with the newly created image

stratus-run-cluster is an extension of stratus-run-instance. It provides the ability to instantiate a group of VMs and configure them as a virtual private cluster with shared storage or/and passwordless access between the nodes. The tool will work with RedHat or Debian based VMs (e.g. CentOS, Ubuntu etc). Typically the VM images should have NFS pre-installed and properly configured in order to allow folder sharing (e.g iptables allowing communication of nfs daemon). If this is not the case the user may install the required packages during VM instantiation using the –add-packages switch. The tool will create a typical master-worker setup with one node acting as the frontend (master) of the cluster and the rest of the nodes as workers. In the typical case all nodes are instantiated from the same image with the same physical profile. The tool provides also the ability to setup non-homogenous clusters in which the master node exhibits different characteristics than the workers.

Apart from the cli parameters accepted by stratus-run-instance, stratus-run-cluster accepts also the following:

--shared-folder=SHARED_FOLDER 
    Folder to share from the master node over NFS

--ssh-hostbased       
    Enable cluster integration through host-based ssh authentication. 
                In this case sshd is setup for passwordless authentication 
                among the cluster nodes. 

--cluster-admin=CLUSTER_ADMIN
                Username for cluster administrator (default root)


--cluster-user=CLUSTER_USER
                Additional user to be created in the cluster. This user account 
                will be created in all the nodes of the cluster.

--mpi-machine-file    
    Defines that a machinefile should be prepared for MPI listing
                available workers and their respective number of cores (slot value).
                The file is saved /tmp/machinefile and can be used directly as a
                parameter for mpirun or mpiexec.

--include-master      
    Defines that the master node should be considered as part of the
                worker nodes. For example this way the name of the master is 
                included in the mpimachine file

--add-packages=ADD_PACKAGES
                Provide comma separated list of additional packages that you wish
                to install

--master-vmid=MASTER_VMID
                VMID of master node if this has been instantiated separately

--tolerate-failures   
    If set true the tool will try to configure the cluster with as many
                nodes as it can, in case some of them fail during instantiation. 
                Default value us FALSE

--clean-after-failure
    In case the tool fails to instantiate all VMs it will try to kill 
                all those that were instantiated thus releasing all resources from
                the cloud. Default value is TRUE

-n INT, --number=INT  
    Number of machines to start for the cluster

Examples

1. Start 4 instances of CentOS OpenMPI appliance using the c1.xlarge profile. Create a user named bobalice and share the home folder. Generate an mpi file and include the master node as part of the workers.

$ stratus-run-cluster --cluster-user=bobalice --shared-folder=/home \
         --mpi-machine-file --include-master --qcow-disk-format -n 4 \
         -t c1.xlarge JAm9q9vBzGJL1klVTe-9xBByfxj

 ::::::::::::::::::::::
 :: Starting cluster ::
 ::::::::::::::::::::::

 :::::::::::::::::::::::::
 :: Starting machine(s) ::
 :::::::::::::::::::::::::
 :: Starting 4 machines
 :: Machine 1 (vm ID: 2748)
  Public ip: 62.217.122.172
 :: Machine 2 (vm ID: 2749)
  Public ip: 62.217.122.173
 :: Machine 3 (vm ID: 2750)
  Public ip: 62.217.122.174
 :: Machine 4 (vm ID: 2751)
  Public ip: 62.217.122.179
 :: Done!
Waiting for all cluster VMs to be instantiated
............
Waiting for all instances to become accessible
...

Master is vm043.one.ypepth.grnet.gr
Worker:vm044.one.ypepth.grnet.gr
Worker:vm045.one.ypepth.grnet.gr
Worker:vm050.one.ypepth.grnet.gr

 :::::::::::::::::::::::
 :: Configuring nodes ::
 :::::::::::::::::::::::
 :: Preparing MPI machine file
 :: Preparing NFS shared folder
 :: Creating additional user
 :: Updating environment variables
 :: Updating hosts file
 :: Done!

2. Start a single node using stratus-run-instance and then start the rest of the cluster using the node from the previous step as the master. Use different instance profile for the master and the workers and a different base appliance. Notice the usage of –context and –add-packages parameters in order to properly configure the master node whose base image is not configured with nfs.

$ stratus-run-instance \
     --context="script_exec=service iptables stop && service portmap start" \
     -t m1.xlarge GQgEmeu7aV2NRaGyAr6FEL3qRET

 :::::::::::::::::::::::::
 :: Starting machine(s) ::
 :::::::::::::::::::::::::
 :: Starting 1 machine
 :: Machine 1 (vm ID: 2752)
  Public ip: 62.217.122.180
 :: Done!

$ stratus-run-cluster -n 3 --qcow-disk-format \
     --add-packages=nfs-utils,openmpi,openmpi-devel \
     --master-vmid 2752 --cluster-user=bobalice \
     --shared-folder=/home --mpi-machine-file \
     --add-packages=nfs-utils,openmpi,openmpi-devel \
     -t c1.xlarge JAm9q9vBzGJL1klVTe-9xBByfxj

 ::::::::::::::::::::::
 :: Starting cluster ::
 ::::::::::::::::::::::

 :::::::::::::::::::::::::
 :: Starting machine(s) ::
 :::::::::::::::::::::::::
 :: Starting 3 machines
 :: Machine 1 (vm ID: 2758)
  Public ip: 62.217.122.191
 :: Machine 2 (vm ID: 2759)
  Public ip: 62.217.122.192
 :: Machine 3 (vm ID: 2760)
  Public ip: 62.217.122.193
 :: Done!
Waiting for all cluster VMs to be instantiated
Waiting for master
.......
Waiting for all instances to become accessible
...

Master is vm051.one.ypepth.grnet.gr
Worker:vm062.one.ypepth.grnet.gr
Worker:vm063.one.ypepth.grnet.gr
Worker:vm064.one.ypepth.grnet.gr

 :::::::::::::::::::::::
 :: Configuring nodes ::
 :::::::::::::::::::::::
 :: Installing additional software packages
 :: Preparing MPI machine file
 :: Preparing NFS shared folder
 :: Creating additional user
 :: Updating environment variables
 :: Updating hosts file
 :: Done!

Connect to the running instance identified by VM ID via SSH. If requested, uses port address translation information associated with the instance.

Usage: stratus-connect-instance [options] [vm-id]

[vm-id] - virtual machine identifier

Run command with -h to the list of self explanatory options.

As a result of running the command user is loged into the specified instance.

~ $ stratus-describe-instance 
id  state     vcpu memory    cpu% ip              name
16  Running   2    2097152   7    62.217.120.188  SlipStream PROD StratusLab
17  Running   2    2097152   7    62.217.120.189  SlipStream PROD Amazon
~ $ stratus-connect-instance 16
Last login: Wed Feb  8 22:49:52 2012 from xxx.aaa.bb
[root@ss-stratuslab ~]# 

stratus-run-benchmark command tests a range of common scientific application patterns: CPU-Intensive, Simulation, Analysis, Filtering, Shared Memory, Parallel, and Workflow.

It covers a large types of applications: sequential, multi-threaded, OpenMP, MPI, i/o parallel, kepler/workflow, master/worker, cpu stress.

The application benchmarks are, by default, parameterized to allow a wide range of input sizes, output sizes, and running times to be evaluated.

The stratus-run-benchmark command allows selecting one specific type of application to test, as it also allows a complete test of all the above types of applications.

The performance of these tests are measured and stored in XML format.

For each type of application we are using specific option.

  --openmp              OpenMP benchmark
  --io                  IO/Parallel, Large input data but relatively small
                        output data, Large input data but relatively small
                        output data and mall input, but significant output
                        data with high-CPU requirements benchmark
  --mpi                 MPI benchmark
  --cpu-intensive       High-CPU requirements but little or no input and
                        output data
  --workflows           Multiple interdependent tasks, Kepler Workflow
                        benchmark
  --all                 Run all benchmarks
  --output-folder=OUTPUT_FOLDER
                        folder for xml output files

stratus-run-benchmark inherits from stratus-run-instance, so the standard stratus-run-instance options can also be used.

The algorithms implemented for each type of application :

1) OpenMP Benchmarks

• Conjugate Gradient Method : Solves linear system Ax=b
• Jacobian type iteration : Solves linear sysrem Ax=b
• Matrix multiplication C=AB

2) MPI Benchmarks

• MPI asynchronous non blocking communication
• MPI synchronous blocking communication
• MPI persistent communication
• MPI standard communication.

3) I/O Benchmarks

• Implements the important features of Parallel I/O
  • Writing to a file: MPI_FILE_write_at
  • Reading from file: MPI_FILE_read_at
  • Both: Reading from a file and writing to another

4) CPU Benchmarks

• Fork Stress
• CPU Stress

5) Workflow Benchmarks

• We are using Kepler Platform for workflows design and management
  • The workflow is built using the customizable components available in Kepler namely: directors, actors, parameters, relations and the ports
  • It executes an OpenMP Application

For testing purposes, we are fixing the parameters (matrix sizes, tolerance, …) for each algorithm.

These algorithms are installed by default in a specific appliance, which could be found in the StratusLab Marketplace.

Produces metadata file (XML format) describing an image provided as an input. This utility is meant to be used to ease the creation of such metadata file and as one of the steps of a new image creation.

Usage: stratus-build-metadata [options] image

image - image to build the metadata for

Supports the following list of self explanatory options.

  --author=NAME         Author of the new image
  --type=NAME           Image type (e.g. base, grid). Default: base
  --kind=NAME           Image kind (e.g. machine, disk). Default: machine
  --os=NAME             Operation system
  --os-version=VERSION  Operation system version
  --os-arch=ARCH        Operation system architecture
  --image-version=VERSION
                        Image version
  --format=FORMAT       Image format (e.g. raw, qcow2). Default: raw
  --hypervisor=NAME     Hypervisor (e.g. kvm, xen). Default: kvm
  --location=URI        Physical location of the image.
  --compression=EXT     Image compression format. One of: gz, bz2
  --comment=TEXT        Comment to append to the manifest file
  --md5=HEX             md5 checksum
  --sha1=HEX            sha1 checksum
  --sha256=HEX          sha256 checksum
  --sha512=HEX          sha512 checksum
  --no-md5              do not calculate md5 checksum
  --no-sha256           do not calculate sha256 checksum
  --no-sha512           do not calculate sha512 checksum

Produces image manifest ready to be signed and uploaded to Marketplace.

stratus-build-metadata \
       --author "Konstantin Skaburskas" \
       --comment "CentOS image." \
       --os centos \
       --os-version 5.5 \
       --os-arch x86_64 \
       --version 1.0 \
       --type base \
       centos-5.5-x86_64.img

You might want to provide –type parameter.

This command will checksum the image as well. Depending on the size of your image this may take minutes.

If checksums are known in advance, they can be provided with

 --md5=HEX             md5 checksum
 --sha1=HEX            sha1 checksum
 --sha256=HEX          sha256 checksum
 --sha512=HEX          sha512 checksum

Required checksum is sha1. To save time one can provide:

 --no-md5              do not calculate md5 checksum
 --no-sha256           do not calculate sha256 checksum
 --no-sha512           do not calculate sha512 checksum

If the future physical location of the image is known it can be provided with ”–location” command line option. If the compression format is known it can be provided with ”–compression” command line option.

As a result, the command produces centos-5.5-x86_64-base-1.0.xml

Next step would be to compress the image, sign metadata file and upload them to Appliance Repository and MarketPlace respectively.

This can be accomplished in two ways.

When the image is located on the machine which happened to hold your secret keys (X509, PKCS12) use stratus-upload-image

For the case when your image is located on remote machine and for obvious reasons you don't want to move your private secrets to that machine you can use a sequence of the following commands:

• stratus-sign-metadata
• [stratus-validate-metada] optional
• stratus-upload-metadata

The commands will require PKCS12 (P12) certificate.

A If you happen know sha1 checksum as well as the size of the image, and don't want to move the .img file to your local machine, the *.img file to stratus-build-metadata, in fact, can be any file. In such case only file size will be taken from the image. So, one can do

$ touch centos.img
$ stratus-build-metadata  ... centos.img
$ $EDITOR centos-5.5-x86_64-base-1.0.xml # change <size> element from 0 to the actual one

B The next step would be to sign the metadata file with

$ stratus-sign-metadata centos-5.5-x86_64-base-1.0.xml

NB! Steps A and B are usually done internally by stratus-upload-image. Those two simple steps let you save time on the movement of the images to the machine that holds your secret keys.

Compresses and uploads the compressed image to Appliance Repository; updates metadata file and uploads it to Marketplace. The following naming convention for the input files is used: filename.xml → filename.img

Requires PKCS12 (P12) certificate and Appliance Repository username/password.

$ stratus-upload-image <metadata-file>

Notable options.

  -C FORMAT, --compress=FORMAT
                        compression format
  -f, --force           force upload of the appliance even if already exists
  --list-compression    list available compression formats
  --with-marketplace    Also upload the metadata file to the marketplace
  --marketplace-only    Only upload the metadata file to the marketplace,
                        don't upload the image to the appliances repository

Prints out locations of uploaded image and/or metadata file.

.

Validates and signs metadata file. Requires PKCS12 (P12) certificate.

Usage: stratus-sign-metadata [options] <metadata-file>

If your PKCS12 certificate doesn't contain email address in its DN you have to provide it with –email parameter.

  --email=EMAIL         email address if not in certificate

Resulting signed metadata file will be stored under the name as the input file and original file will be moved to *.orig

~ $ stratus-sign-metadata -vvv CentOS-5.5-x86_64-base-1.0.xml 
    Loading signature jar file: /var/lib/stratuslab/java/marketplace-metadata-0.0.7-jar-with-dependencies.jar
    Calling: java -cp /var/lib/stratuslab/java/marketplace-metadata-0.0.7-jar-with-dependencies.jar eu.stratuslab.marketplace.metadata.SignMetadata CentOS-5.5-x86_64-base-1.0.xml CentOS-5.5-x86_64-base-1.0.xml.new /home/konstan/.globus/usercert.p12 xxxxxxx
    Renaming input file from CentOS-5.5-x86_64-base-1.0.xml to CentOS-5.5-x86_64-base-1.0.xml.orig
    Renaming output file from CentOS-5.5-x86_64-base-1.0.xml.new to CentOS-5.5-x86_64-base-1.0.xml
    Metadata file successfully signed: CentOS-5.5-x86_64-base-1.0.xml
~ $ 

Validates metadata file: all elements and signature. Will report on any missing required elements.

Usage: stratus-validate-metadata [options] [manifest-file]

Expects manifest file as an input.

In case the provided manifest is valid prints:

Valid: CentOS-5.5-x86_64-base-1.0.xml

In case the provided manifest is invalid the utility will print the reason as well:

Invalid: dummy-base.xml.orig
no signature

~ $ stratus-validate-metadata -vvv CentOS-5.5-x86_64-base-1.0.xml
    Loading signature jar file: /var/lib/stratuslab/java/marketplace-metadata-0.0.7-jar-with-dependencies.jar
    Calling: java -cp /var/lib/stratuslab/java/marketplace-metadata-0.0.7-jar-with-dependencies.jar eu.stratuslab.marketplace.metadata.CheckMetadata CentOS-5.5-x86_64-base-1.0.xml
Valid: CentOS-5.5-x86_64-base-1.0.xml
~ $

Uploads metadata file to Marketplace.

Usage: usage: stratus-upload-metadata [options] <metadata-file>

Requires metadata file.

URL of the uploaded to the Marketplace metadata file.

~ $ stratus-upload-metadata --marketplace-endpoint http://62.217.120.176:8081 CentOS-5.5-x86_64-base-1.0.xml
http://62.217.120.176:8081/metadata/No5o-5ea0sNMlW_75VgGJCv2AcJ/Konstantin.Skaburskas@cern.ch/2011-07-01T14:56:06Z
~ $

Deprecates metadata entry describing an image in the Marketplace.

Usage: usage: stratus-deprecate-metadata [options] <image id>

Requires an image ID.

Notable options.

  --email=EMAIL         email address of endorser of metadata entry
  --created=CREATED     date of metadata entry to be deprecated, latest entry
                        will be deprecated if not provided
  --reason=TEXT         Comment to append to deprecation

Full URL of the deprecated image metadata.

~ $ stratus-deprecate-metadata –marketplace-endpoint http://62.217.120.176:8081 PvitUfM-uW2yWakWUNmd-TSPOiy –email airaj@lal.in2p3.fr http://62.217.120.176:8081/metadata/PvitUfM-uW2yWakWUNmd-TSPOiy/Konstantin.Skaburskas@cern.ch/2012-02-12T20:42:12Z ~ $

Using stratus-create-image one can create a new appliance based on a given one (base image/appliance) with certain packages installed, scripts run, files/directories cleaned up.

Usage: stratus-create-image [options] base-image

image - Marketplace image ID

It is mandatory to provide the following parameters:

  --author=NAME         author of the new image
  --author-email=EMAIL  Email address of the author of the new image
  --comment=TEXT        description of the new image

Email address will be used to notify the image creator about the new image availability. The received email will contain all the required details on how to proceed with the usage of the new image.

To install additional packages (rpm or deb) one can provide a list of packages along with a list of repository endpoints for the packages to be installed from

  -a PACKAGE, --packages=PACKAGE
                        packages to install on the machine (comma separated)
  --extra-os-repos=URL  extra repositories to install [--packages] from (comma
                        separated). For apt "base_uri distribution
                        [component1] ..."

Example of installing of httpd (from OS repository) and python-dirq from EPEL (assumes that the base image uses RPM):

  --packages httpd,python-dirq --extra-os-repos http://download.fedora.redhat.com/pub/epel/5/i386/

Installer will be recovered from the name of OS as defined in the manifest of the base image.

It's possible to run scripts on the base image.

  -s FILE, --scripts=FILE
                        scripts to execute on the VM (comma separated)  

The ”-s/–scripts” option accepts comma separated list of scripts located on the user machine that will be run on the image. User can provide options to the scripts as well. In this case, the whole command should be wrapped into double quotes.

  --scripts "/path/script-one -a A -b B","/path/script-two -c C"

As a process of the image cleanup one can request deletion of files/directories. This is the last step in the process of the new image creation.

  --exclude=FILE        exclude file/dir from new image (comma separated).
                        Removed by default: /tmp/*, /etc/ssh/ssh_host_*,
                        /root/.ssh/{authorized_keys,known_hosts}

Images have to be versioned. The versioning can be automatic or manual.

  --image-version=VERSION
                        version for the new image. By default a minor version
                        of the base image is incremented.

The newly created image stored in PDISK server of the Cloud instance the request was made to. User will receive the following email:

Subject: New image created Di65iu2MkDHgGJyVGOq0niPLkqj
Attachment: manifest-not-signed.xml
Content:

Image creation was successful.
New image was stored in local PDISK service https://onehost-5.lal.in2p3.fr:8445/disks/6f6cb722-3055-4eb9-b550-4cafcfd17b7e
Image manifest with ID Di65iu2MkDHgGJyVGOq0niPLkqj was signed with dummy certificate and uploaded to http://marketplace.stratuslab.eu.
Alternatively, you can sign attached manifest and upload to Marketplace with:
stratus-sign-metadata <manifest file>
stratus-upload-metadata <manifest file>

NB! The validity of the manifest is 48 hours. Please change it!

The validity of the signing certificate is 2 days.

Cheers.

Example of creation of bioinformatics compute image.

$ stratus-create-image --author-email konstan@sixsq.com --author "John Doe" \
  --comment "Bioinformats compute image." \
  --packages wget,gcc-c++,make \
  --scripts "/home/user/bioapps_installer.sh -s clustalw2" \ 
  --exclude /etc/resolve.conf \ 
  --version 1.21 \
  --image-group bio.compute \
  OMd8M7ixG3toGqm8C1MhUphMJWF

...
 ::::::::::::::::::::::::::::::::::::::::
 :: Finished building image increment. ::
 ::::::::::::::::::::::::::::::::::::::::

 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 :: Please check konstan@sixsq.com for new image ID and instruction. ::
 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 :: Shutting down machine

OMd8M7ixG3toGqm8C1MhUphMJWF - MarketPlace image ID of CentOS v5.5 x86_64.

Steps performed on the base image:

1. wget, gcc-c++ and make packages will be installed
2. “bioapps_installer.sh -s clustalw2” script will be run
3. /etc/resolve.conf file will be deleted along with the default files/dirs (see ”–exclude” parameter description).

Packages installer will be inferred from OS name obtained from the base image. As ”–image-version” was not provided, the version number got automatically incremented.

The new image will be stored in the PDISK service of the Cloud instance the request was made to and the manifest describing the newly created image will be signed with short-lived self-signed certificate and uploaded to Marketplace. User will have to check its mailbox for new email (subject: “New image created <image ID>”) with the instruction on how to proceed.

Check stratus-create-image -h for more options.

Alternative manual way to create a new image would be to

0. NB! the base image has to support ACPI shutdown call

1. launch an instance of the base image via

  stratus-run-instance --save --author-email <email> <base-image ID>

2. ssh to the instance and apply required modifications

3. run

  stratus-shutdown-instance <instance ID>

4. user receives email with details on how to proceed with the newly created image

Create a new persistent disk in the persistent disk storage service defined in the user configuration file (pdisk_endpoint) or in the command parameters (–pdisk-endpoint).

stratus-create-volume --size SIZE [--tag NAME]

• -s, –size SIZE: The size of the volume, in GiBs.

• -t, –tag NAME: Tag used by the user to identify his disk.

• –private: Disk is private, you are the only one who can see it, use it and delete it. This is the default option.
• –public: Disk is public. Everyone can see it and use it but you are the only one that can delete it.

The newly created disk UUID on the service

This example create a disk of 2GiBs with the tag “grid-test:ce”

PROMPT> stratus-create-volume -s 2 -t "grid-test:ce"
DISK acfcda7d-d929-4fd0-87b0-1523a720368c

Delete a persistent disk in the persistent disk storage service defined in the user configuration file (pdisk_endpoint) or in the command parameters (–pdisk-endpoint).

stratus-delete-volume VolumeUUID ...

• VolumeUUID: The ID of the volume to delete.

The deleted disk UUID on the service

This example delete two persistent disks.

PROMPT> stratus-delete-volume acfcda7d-d929-4fd0-87b0-1523a720368c 7fee5536-9db2-4bdc-a4cc-3a3ee50a23d1
DELETED acfcda7d-d929-4fd0-87b0-1523a720368c
DELETED 7fee5536-9db2-4bdc-a4cc-3a3ee50a23d1

List available disk for the current user in the persistent disk storage service defined in the user configuration file (pdisk_endpoint) or in the command parameters (–pdisk-endpoint).

You can filter the results to return information only about persistent disks that match criteria you specify. For example, you could get information about disks whose are not in use.

You can specify multiple filters (e.g., the persistent disks is in use, and it is tagged with a particular value). The result includes information for a particular disk only if it matches all your filters. If there's no match, no special message is returned; the response is simply empty.

You can use standard regular expression to match the required persistent disks. Filters can be build with all the properties of the disk.

stratus-describe-volumes [VolumeUUID ...] [[--filter name=value] ...]

• –filter name=value: A filter limiting the results

• VolumeUUID: Restrict search to those disks UUIDs

Return a list of the matching persistent disks with there properties.

This example show only disks with a tag starting with grid.

PROMPT> stratus-describe-volumes -f "tag:^grid.*"
:: DISK ba965fd0-6a27-4bcb-9cb3-dca74a2a5171
created: 2011/07/25 14:18:38
visibility: public
tag: grid-software-public
owner: test2
size: 3
users: 0
:: DISK 5822c376-9ce1-434e-95d1-cdaa240cd47c
created: 2011/07/25 14:17:37
visibility: private
tag: grid-ce - LAL tests
owner: test
size: 5
users: 0

Attach a persistent disk to a running instance and expose it to the VM.

Running instance needed to have acpiphp kernel module loaded.

stratus-attach-volume --instance VM_ID VolumeUUID ...

• VolumeUUID: The IDs of the volume to attach.

• VM_ID: The ID of the instance to which the volume attaches.

The disk UUID and the device on which it have been attached.

This example attach two persistent disks.

PROMPT> stratus-attach-volume -i 24 1e8e9104-681c-4269-8aae-e513c6723ac6 5822c376-9ce1-434e-95d1-cdaa240cd47c
ATTACHED 1e8e9104-681c-4269-8aae-e513c6723ac6 in VM 24 on /dev/vda
ATTACHED 5822c376-9ce1-434e-95d1-cdaa240cd47c in VM 24 on /dev/vdb

Detach a persistent disk from a running instance.

Important: Make sure to unmount any file systems on the device within your operating system before detaching the volume. Failure to unmount file systems, or otherwise properly release the device from use, can result in lost data and will corrupt the file system.

Note: If you have attached the volume at instance start-up, it cannot be detached while the instance is in the ‘running’ state. To detach the volume, stop the instance first.

stratus-detach-volume --instance VM_ID VolumeUUID ...

• VolumeUUID: The IDs of the volume to detach.

• VM_ID: The ID of the instance.

The disk UUID and the device from which it have been detached.

This example detach two persistent disks.

PROMPT> stratus-attach-volume -i 24 1e8e9104-681c-4269-8aae-e513c6723ac6 5822c376-9ce1-434e-95d1-cdaa240cd47c
DETACHED 1e8e9104-681c-4269-8aae-e513c6723ac6 from VM 24 on /dev/vda
DETACHED 5822c376-9ce1-434e-95d1-cdaa240cd47c from VM 24 on /dev/vdb

Produces MD5 and CRYPT hashes of the provided password.

Usage: stratus-hash-password [options]

.

.

~ $ stratus-hash-password 
username:
password:
retype password:
MD5:054e239ea51513f828c2f82d724579c5
CRYPT:..yLg4lweV.hY
~ $