FAQ C

Conceptual

CQ1: What are the differences between a Virtual Application (VApp) and a Virtual Application Submitter (VAppS)?

CA1: You can deploy multiple instances of Virtual Application (VApps) in "immediate" mode by typing the command aiattach <vapp type> on CBTOOL's CLI. It is useful if you want to deploy a fixed number Virtual Applications and then collect data on the VApp's application performance. A VApp deployed explicitly will run until you remove it. Virtual Application Submitters (VAppS), on other side, keep deploying Virtual Applications, running it for a specified time, and then removing it. Please take a look at the [CBTOOL Key Concepts] (https://github.com/maugustosilva/cbtool/wiki/DOC:-Key-Concepts-and-Objects)

Back

---

CQ2: The documentation refers to Virtual Application (VApp) and a Virtual Application Submitter (VAppS), but on CBTOOL's CLI, messages and commands keep referring to Application Instance (AI) and Application Instance Deployment Request Submitter (AIDRS).

CA2: For "historical" reasons, the code still uses the "old" nomenclature (it will be changed someday). For now, just keep in mind:

Virtual Application (VApp) = Application Instance (AI)

Virtual Application Submitter (VAppS) = Application Instance Deployment Request Submitter (AIDRS)

Back

---

CQ3: Reading here and here, I understand that there are in fact two ways to alter an attribute on an Object: (a) by changing my private cloud configuration file or (b) by issuing cldalter, rolealter, typealter and patternalter commands on the CLI. That is a tiny bit confusing. Are there any guidelines on when to use (a) or (b)?

CA3: While any Object could be changed by adding overriding attributes on your [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2), we believe that it is a "best practice" to alter any parameters on the Configuration (Global) Objects that refer to your particular environment in your [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2), but alter any parameter on objects that refer to any VM, VApp or VAppS directly on the CLI or API (i.e., directly on the Object Store). It means that any experiment trace file submitted to CBTOOL should explicitly include the command to alter these Configuration Objects, increasing the reproducibility of your experiment, should you send it to another person to be re-run. The following table summarizes it, with some examples:

Configuration Object	Altering method	Example	Comment
[OBJECTSTORE]	private configuration file	[OBJECTSTORE] ... PORT = 10000 ...	Refers only to *your* specific environment
[LOGSTORE]	private configuration file	[LOGSTORE] ... VERBOSITY = 5 ...	Refers only to *your* specific environment
[METRICSTORE]	private configuration file	[METRICSTORE] ... DATABASE = mymetrics ...	Refers only to *your* specific environment
[SPACE]	private configuration file	[SPACE] ... STORES_WORKING_DIR = /home/$MAIN_USERNAME/stores ...	Refers only to *your* specific environment
[TIME]	private configuration file	[TIME] ... STORES_WORKING_DIR = /home/$MAIN_USERNAME/stores ...	Refers only to *your* specific environment
[VMC_DEFAULTS]	private configuration file	[VMC_DEFAULTS] ... DISCOVER_HOSTS = $True ...	Refers only to *your* specific environment
[VM_DEFAULTS]	CLI/API or experiment trace file	cldalter vm_defaults run_generic_scripts=false	Refers only to an specific experiment
[VM_TEMPLATES]	private configuration file (cloud-specific)	[VM_TEMPLATES : OSK_CLOUDCONFIG] ... HADOOPMASTER = size:m1.small, imageid1:cloudbench_root ... [VM_TEMPLATES : EC2_CLOUDCONFIG] ... HADOOPMASTER = size:m1.large, imageid1:ami-b3e44dda ...	Refers only to *your* specific environment
[AI_DEFAULTS]	CLI/API or experiment trace file	cldalter ai_defaults attach_parallelism=5	Refers only to an specific experiment
[AI_TEMPLATES]	CLI/API or experiment trace file	typealter daytrader db2_on_ramdisk=true	Refers only to an specific experiment
[AIDRS_DEFAULTS]	CLI/API or experiment trace file	cldalter aidrs_defaults daemon_parallelism=100	Refers only to an specific experiment
[AIDRS_TEMPLATES]	CLI/API or experiment trace file	patternalter simplenw iait=10	Refers only to an specific experiment

Back

---

CQ4: I want to deploy a single VM or single Virtual Application with different parameters (i.e., I don't want to alter the parameters for all subsequent VMs or VApps, but for the one). How can I do that?

CA4: As previously discussed the value of a given parameter for an Object (e.g., VMs, VApps) is read just once if defined on the [private configuration file] (https://github.com/maugustosilva/cbtool/wiki/FAQ-S#wiki-sq2) (during the initial execution of CBTOOL with --soft_reset or --hard_reset parameters). If a particular parameter has to be changed after a reset, the only option is the use of the cldalter (or its Object-specific versions, rolealter for VMs, typealter for _VApp_s and patternalter for _VAppS_s) to change a parameter directly on the Object Store.

Both of these methods for parameter value change can become a problem if your experiment requires that "just the next _VApp" needs to be deployed with different parameters. To this end, you can dynamically override the parameters defined on the Object Store with different values for a single VM or VApp deployment only.

For instance, if the objective is to deploy just a single VM, with the role tinyvm, attached to a 10 GB volume mounted on the directory /my_data_dir, there are specific parameters on the CLI commands or API calls that can be employed:

• CLI: vmattach tinyvm auto empty default none cloud_vv=10,data_dir=/my_data_dir (where the parameters auto empty default none are kept as defaults)
• API: apiconn.vmattach(<CLOUDNAME>, "tinyvm", temp_attr_list = "cloud_vv=10,data_dir=/my_data_dir")

In case of the Virtual Applications, it is possible to alter parameters applicable to both the whole VApp or to specific VMs within a given VApp. For instance, to deploy of VApp of the open_daytrader type, with a load balancer, and with a 10 GB volume only for the VM with role mysql, the CLI and API invocations are described as follows:

• CLI: aiattach open_daytrader default default none none none load_balancer=true,mysql_cloud_vv=10,mysql_data_dir=/mysqldata (where the parameters default default none none none are kept as defaults).
• API: apiconn.appattach(<CLOUDNAME>, "open_daytrader", temp_attr_list = "load_balancer=true,mysql_cloud_vv=10,mysql_data_dir=/mysqldata")

Back

---

CQ5: In the [USER-DEFINED] section of many clouds (e.g., OpenStack, Amazon EC2) there are two attributes relating to SSH keys (e.g., OSK_KEY_NAME and OSK_SSH_KEY_NAME for OpenStack). This seems confusing. What exactly are these?

CA5: UPDATE: CBTOOL can now automatically create SSH keys. A typical user will not have to deal with these complexities anymore.

Let's use OpenStack (OSK) as an example. The OSK_KEY_NAME is the name of the (public) key that will be "injected" on an image before it is booted. For instance, in OpenStack, the key is normally injected in /root/.ssh/authorized_keys, allowing a user to login on a VM after the boot as root. This attribute refers to a key that is managed directly by the OpenStack cloud.

On other hand, OSK_SSH_KEY_NAME is the name of the key used to login on a VM as the user (non-root) specified by OSK_LOGIN. This key will not (necessarily) be injected on the image. It is expected that the key and username specified by OSK_SSH_KEY_NAME and OSK_LOGIN are pre-defined on the VM. These attributes are not managed (or known at all) by the OpenStack cloud.

Back