DOC: Detailed Virtual Application Deployment Steps

Notes:

• Step 1 is optional. Virtual Applications can be deployed explicitly by the experimenter (using either the CLI or GUI) or implicitly through one or more VApp Submitters. If the Virtual Application is being explicitly deployed, then the timeline goes straight to Step 2 (i.e., the CBTOOL's API server directly starts a new Virtual Application Deployer (python) daemon, instead of a Virtual Application Submitter daemon.

• The AIDRS_TEMPLATES, AI_TEMPLATES, VM_DEFAULTS and VM_TEMPLATES are configuration objects, explained here.

• The behavior of the VM creation thread between steps 4 and 5 is controlled by the attribute "CHECK_BOOT_STARTED" on the configuration object VM_DEFAULTS (default value is "poll_cloud"). Just add it to your "private" configuration file (by the default, CBTOOL looks for a file called (your username)_cloud_definitions.txt in ~/cbtool/configs) to change the behavior. Setting the attribute "CHECK_BOOT_STARTED = subscribe_on_starting" on VM_DEFAULTS will make the VM creation thread subscribe to a channel and wait for the message "(my VM uuid) has started" before proceeding (it is assumed that this information will be determined by an external process, which will be in charge of publishing the appropriate message).

• The behavior of the VM creation thread between steps 5 and 6 is controlled by the attribute "CHECK_BOOT_ENDED" on the configuration object VM_DEFAULTS (default value is "tcp_on_22"). Just add it to your "private" configuration file to change the behavior. Setting the attribute "CHECK_BOOT_ENDED = subscribe_on_booting" on VM_DEFAULTS will make the VM creation thread subscribe to a channel, and wait for the message "(my VM IP) is booted" before proceeding. Setting the attribute "CHECK_BOOT_ENDED = wait_for_x" will make the VM creation thread just wait for x seconds and then proceed (i.e., it will just assume that the VM was booted after x seconds).

• Between steps 6 and 7, the VM creation thread uses rsync to send a copy of the most current CBTOOL code from the Orchestrator node to the VM (this ensures that VM is always executing the most current code). This step can be bypassed by setting the attribute "TRANSFER_FILES = $False" on the configuration object VM_DEFAULTS (again, on your "private" configuration file).

• The script "cb_post_boot.sh", run by the VM creation thread between steps 7 and 8, basically configures the VM hosts file (so each VM can now about other VMs on the same VApp), sets up the ntp server (having the VMs and the Orchestration Node synchronized is very important for data collection) and starts the OS resource usage collection daemon (ganglia). This step can be bypassed by setting the attribute "RUN_GENERIC_SCRIPTS = $False" on the configuration object VM_DEFAULTS (always on your "private" configuration file).

• The scripts run by the Virtual Application Deployer daemon on each VM between steps 8 and 9 are application-specific. Their execution is what will effectively start the load generation on the VApp (more information here). For debugging purposes, this execution can be bypassed by setting the attribute "RUN_APPLICATION_SCRIPTS = $FALSE" on the configuration object AI_DEFAULTS (also on your "private" configuration file.).

• The mgt_* identifiers are used on the first plot on auto generated plots.