Changes:

Feature: External Volume attachment/detachment support. When deploying a new VApp (AI),
CB can be instructed to create an additional (persistent) volume and attach it to each VM
with specific roles.
For instance, issuing the commands “typealter hadoop hadoopslave_cloud_vv=50” and then
“aittach hadoop” will cause CB to create a new 50 GB storage volume for each new VM with
the role “hadoopslave”. The storage volume is automatically attached to the VM, and also
automatically destroyed when the VM is terminated (if the termination is performed through
 CB). Right now, the two Clouds with support for Volume creation are Amazon EC2 and
OpenStack. VERY IMPORTANT: The actual application-specific startup scripts will have to
deal with the newly created volume, creating a partition and a filesystem on it (it might
increase the VApp deployment time significantly). Currently, none of the available
application scripts are prepared to deal with external volumes.

Feature: “Null Operation” cloud adapter, used to deploy VApps in pre-created VMs. To use
this new adapter, the user has to specify “nop” as the model of the cloud to be attached
(e.g., “cldattach nop TESTCLOUD”) and then has to change the Virtual Application templates
to manually indicate the IP addresses of the already created VMs. Example: manually create
4 VMs containing the appropriate Hadoop/HiBench binaries on any cloud (it could be even
one of the cloud models that are already supported by CB), add the assigned IPs to the
VApp template (e.g., “typealter hadoop hadoopmaster_cloud_ips=10.20.80.31”,
“typealter hadoop hadoopslave_cloud_ips=10.20.80.33;10.20.80.34;10.20.80.36;10.20.80.32”)
and then just deploy the VApp (“aittach hadoop”). CB will configure and start the
actual application on the VMs as it would with any other cloud adapter, allowing the same
configurable load intensity and collecting application and guest OS performance as usual.
There are several possible uses for this feature, ranging from testing unsupported
“PaaS-like” clouds to VApp deployment automation debugging (when scripts failed to
execute with this NullOp adapter, the “VM termination” just issues a couple of cleanup
commands on the VM through SSH, allowing the same VM to be re-utilized).

Feature: A new parameter, “debug_remote_commands” applicable to both VMs (i.e.,
“cldalter vm_defaults debug_remote_commands=true”) and VApps
(“cldalter ai_defaults debug_remote_commands=true”) can be combined with the options
described in the answer to question 14 on the FAQ to allow a much easier debugging of the
remote commands executed on VM or VApp. Instead having to look at the logs, the actual
commands that would be executed on a VM are displayed directly on the CLI (Each
non-executed script is prefixed by the message “This is the command that would have been
 executed from the orchestrator:”).

Feature: A short reimplementation of the API calls "hostfail" and "hostrepair",
allowing these to target specific services on specific hosts on a cloud.
Unfortunately, SSH access to the hosts is required. For instance, a command like
"hostfail <host_name> keystone" would kill the keystone service on a host in an
OpenStack cloud.

Bugfix: When running the “airesize” command, the newly created VMs did not have the
attribute “base_type” properly assigned. Without this attribute, CB was unable to know
which application-specific scripts had to be copied to CB’s home directory on the VMs.

Code Maintenance: Added SPEC-specific VApp types (Mweb and SPECimap) to the internal
repository.

Code Maintenance: automated graph/plot generation R scripts (cbplot) now detect and
install required libraries automatically. Tables are beautifyed with bi-color rows
and appropriate page scaling.
Code directory cleanup
merged with master