HOWTO: Deploy your first virtual application - ibmcb/cbtool GitHub Wiki
Deploying your first "nullworkload" Virtual Application type
- Information on the "nullworkload" Virtual Application type can be be obtained through the command
typeshow nullworkload :
(TESTOPENSTACK WALKTHROUGH) typeshow nullworkload
The AI with the type nullworkload has the following configuration on experiment (Cloud TESTOPENSTACK) :
description: Deploys one or more VMs, and then continuously executes a variable-length
sleep, followed by the reporting of fake performance numbers at the end.
- LOAD_PROFILE possible values: "default" (since this is just sleep call,
multiple profiles don't make any sense).
- LOAD_LEVEL meaning: does not matter/do not care.
- LOAD_DURATION meaning: the length of the sleep call.
- COMMENT: One of the "Synthetic" Workloads. This a very useful workload to test
a Cloud's management/infrastructure in an "ideal" or "baseline" scenario
(without any resource starvation from workloads on compute nodes). The fact
that, despite not executing any actual meaningful workload on the VM, both Guest
OS (actual) and Application metrics are reported back to CB's Metric Store,
makes it also an interesting "sanity check" workload.
# Attributes MANDATORY for all Virtual Applications:
sut: tinyvm
load_balancer_supported: False
resize_supported: True
regenerate_data: False
role_list: tinyvm
load_generator_role: tinyvm
load_manager_role: tinyvm
metric_aggregator_role: tinyvm
capture_role: tinyvm
load_profile: default
load_level: uniformIXIXI1I100
load_duration: 30
reported_metrics: bandwidth,throughput,latency,completion_time,errors,quiescent_time
# Virtual Application-specific MANDATORY attributes:
tinyvm_setup1: cb_start_nothing.sh
tinyvm_reset1: cb_reset_nothing.sh
start: cb_run_nothing.sh
# Virtual Application-specific OPTIONAL attributes:
category: fake
(TESTOPENSTACK WALKTHROUGH)
- We can now attempt to deploy the first instance of the "nullworkload" VApp:
(TESTOPENSTACK WALKTHROUGH) aiattach nullworkload
status: ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265) was successfully defined on OpenStack Cloud "TESTOPENSTACK" (will now be fully deployed)
status: Starting instance "cb-cbuser-TESTOPENSTACK-vm5-tinyvm-ai-1" on OpenStack Cloud, using the image "cb_nullworkload" (a1372342-e819-11e6-bcc9-6cae8b2ac98e qemu) and size "m1.tiny" (40adaa80-06dc-477c-a748-d469ee0b5fd7), connected to network "flat_net", on VMC "RegionOne", under tenant "default", injecting the contents of the pub ssh key "cbuser_cbtool_rsa" (userdata is "None").
status: Waiting for vm_6 (9D8B087C-4FB2-588F-849E-04887584D0F6), part of ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265), to start...
status: Trying to establish network connectivity to vm_6 (9D8B087C-4FB2-588F-849E-04887584D0F6), part of ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265), on IP address 9.47.174.4 (using method "tcp_on_22")...
status: Command "/bin/true" failed to execute on hostname 9.47.174.4 after attempt 0. Will try 720 more times.
status: ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265) was successfully defined on OpenStack Cloud "TESTOPENSTACK" (will now be fully deployed)
status: Performing generic application instance post_boot configurationon all VMs belonging to ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265)...
status: Running application-specific "setup" configuration on all VMs belonging to ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265)...
status: QEMU Scraper will NOT be automatically started during the deployment of ai_1 (D0CA37BB-A173-508C-9B6A-D5621D50F265)...
AI object D0CA37BB-A173-508C-9B6A-D5621D50F265 (named "ai_1") sucessfully attached to this experiment. It is ssh-accessible at the IP address 9.47.174.4 (cb-cbuser-TESTOPENSTACK-vm5-tinyvm-ai-1).
You have sucessfully deployed your first workload. You can check the CB's GUI (go to Dashboard -> Application Performance) or run "monlist VM" on the CLI. If you see application samples, this means that the initial configuration is complete.
Restart the tool with "cb --soft_reset".
To configure instances for the deployment of other workloads, just execute "vmattach check:cb_nullworkload:<USERNAME FOR LOGIN>:<WORKLOAD TYPE OF YOUR CHOICE>", followed "vmcapture youngest <IMAGE_NAME_DEFINED_ON_THE_WORKLOAD_ROLES>"
- Wait a few minutes and the use the (previously discussed) command
monlist VM to ensure that the (fake) application executed inside the single instance that composed a "nullworkload" Virtual Application is publishing metric samples:
(TESTOPENSTACK WALKTHROUGH) monlist VM
The following VMs reported management metrics:
Name |Age (seconds) |Experiment id |Number of samples
vm_1 |232853 |EXP-02-11-2017-12-11-07-AM-UTC |1
vm_2 |232626 |EXP-02-11-2017-12-11-07-AM-UTC |1
vm_3 |232176 |EXP-02-11-2017-12-11-07-AM-UTC |1
vm_4 |1099 |EXP-02-11-2017-12-11-07-AM-UTC |1
vm_5 |599 |EXP-02-11-2017-12-11-07-AM-UTC |1
The following VMs reported runtime (OS) metrics:
Name |Age (seconds) |Experiment id |Number of samples
The following VMs reported runtime (Application) metrics:
Name |Age (seconds) |Experiment id |Number of samples
vm_5 |33 |EXP-02-11-2017-12-11-07-AM-UTC |12