New workloads:

- Apache Giraph: an iterative graph processing system built for high scalability.

Changes:

1) Do not check for the existence of a floating IP pool in OpenStack, unless the
VM_DEFAULTS attribute CB_JUMPHOST is set to "True" (i.e., $True) in OpenStack. Not every
OpenStack installation uses floating IPs to provide external reachability for VMs (e.g.,
Flat networking could be used instead) and CB shouldn't check for it unless really needed.

2) Cleanup in the logging output. The default verbosity level - 5 - was way too verbose
to be effective as a debugging tool (it was quite overwhelming, actually). Now 3 more
verbosity levels were created (1 - 8), being the level 5 focused on ACTIVE operations
on a Cloud (such, as VM and VV creation).

3) The Global Object VM_DEFAULTS has a new attribute, LEAVE_INSTANCE_ON_FAILURE. This
attribute, when set to $True (default is $False), instructs CB to leave VMs in place,
in case the attachment operation is considered failed by CB. Very useful for "post-mortem"
analysis. IMPORTANT: Currently, implemented only for the OpenStack Cloud Adapter.

4) Several bugfixes for the OpenStack Cloud Adapter.

5) Bugfix for a case where the user specify the JUMP_HOST = $True (i.e., automatically
create the VM jump box) but does not have the image "cb_nullworkload" registered on the Cloud.

6) Added proper description (plus additional code cleanup) for Virtual Workloads
redis-ycsb and hpcc

7) The functions service_restart_enable, and services_stop_disable were re-written to
support services in Ubuntu and RHEL with multiple different mechanisms (e.g., systemctl,
service/rc.d, service/chkconfig)

8) Improvements on "stats" API call. First of all, the data returned by the API is a JSON
object, instead of a list of lists (much easier to parse and use). Second, the API call
now supports two options: "object_type" (default is "all") and "output" (default is
"print"). When calling stats from the API, the user can specify output to be "json" and
then he will just receive back a JSON object. The default value "print" is used by the
CLI, where printing a properly formatted response is important. The second improvement is
the capability to, if allowed by the cloud, to include the number of VMs reported directly
by it on the list of counters for the "VM" object.

9) Implemented a primitive "backoff" algorithm for cases where the instance boot
completion is checked through ssh over a jumphost. After one third of attempts is made,
the default timeout for the ssh (which is half of the value of the "update_frequency" for
each VM) will doubled, being doubled again after two thirds of the attempts are made.

10) Updated automated installer. Now the installer requires the specification of a "role"
("-r", "--role") to the node where it is run (possible values are "orchestrator" and
"workload"). The automated installer now takes care of deactivating firewalld,
iptables and ipfw on workload VMs.

11) Refactoring on the core "operations" code. a) Now, a particular instantiation
of a cloud operations class, for a given user and experiment identifier is stored on
shared dictionary. This will ensure that this instantiation can be re-utilized across
multiple operations, reducing the need for repeated dynamic module imports. b) A new
shared variable, "expid", caches the result of query to the "time" global object on the
Object Store. This means a reduced number of queries across multiple operations.

12) Support for PubSub through both CLI and API, including setting of timeouts for
subscribers. The command "msgpub VM mychannel mymessage" (the API equivalent is
api.msgpub("TESTSIMCLOUD", "VM", "mychannel", "mymessage")) will publish the message
"mymessage" on the channel "VM:mychannel". The command "waiton VM mychannel mymessage
120" (the API equivalent is api.waiton("TESTSIMCLOUD", "VM", "mychannel", "mymessage",
120)) will cause the CLI/API client to block waiting for the message "mymessage" to be
published on the channel "VM:mychannel" with a timeout of 120 seconds.

13) A new VM attribute, "comments", is now automatically stored on the Metric Store. This
is very handy if, during an experiment, an user wishes to "annotate" certain VMs for later
analysis.

14) In OpenStack clouds, extract the total time to complete the provisioning request
directly from nova API, instead of relying on the value determined by CB (e.g., through
polling). Since the total time reported by CB and by nova API differ, the actual time
spent by CB waiting for the provisioning request to complete is added to VM's "comments"
attribute.
Merge branch 'master' of github.com:ibmcb/cbtool