# KloudBuster Default configuration file
#
# This file can be copied and used as a template to specify different settings,
# then passed to KloudBuster using the '--config-file <path>' option.
#
# NOTE: In the copy, properties that are unchanged (same as default) can be simply
# removed from the file.

# =====================================================
# COMMON CONFIG OPTIONS FOR BOTH SERVER AND CLIENT SIDE
# =====================================================

# Name of the image to use for all test VMs (client, server and proxy)
# The image name must exist in OpenStack and built with appropriate packages.
# The default test VM image is named "kloudbuster_v<version>" where
# <version> is the KloudBuster test VM image version (e.g. "kloudbuster_v3")
# Leave empty to use the default test VM image (recommended).
# If non empty use quotes if there are space characters in the name (e.g. 'my image')
image_name:

# Keystone admin role name (default should work in most deployments)
keystone_admin_role: "admin"

# Cleanup all kloudbuster resources upon exit
# If set to False, resources created will not be deleted on exit and the user
# will have to execute the cleanup script later to remove all these resources
cleanup_resources: True

# VM creation concurrency
# Specifies how many VMs will be created at a time. Larger numbers can be used
# but will not necessarily shorten the overall staging time (this will largely
# depend on the scalability of the OpenStack control plane).
# Well tuned control planes with multiple instances of NOVA have shown to
# support a concurrency level of up to around 50
vm_creation_concurrency: 5

# Public key to use to access all test VMs
# If empty will default to the user's public key (~/.ssh/id_rsa.pub) if it
# exists, otherwise will not provision any public key.
#
# NOTE: SSH access to the test VMs launched by kloudbuster is not required,
# but can be handy if the user wants to ssh manually to any of them (for
# example to debug)
public_key_file:

# ==========================
# SERVER SIDE CONFIG OPTIONS
# ==========================
server:
    # Flavor to use for the test images
    flavor:
        # Number of vCPUs for the flavor
        vcpus: 1
        # Memory for the flavor in MB
        ram: 2048
        # Size of local disk in GB
        disk: 20

    # Number of tenants to be created on the cloud
    # KloudBuster will also create 1 user automatically for each tenant
    number_tenants: 1

    # Number of routers to be created within the context of each User
    routers_per_tenant: 1

    # Number of networks to be created within the context of each Router
    # Assumes 1 subnet per network
    # Note that you will need as many available floating IPs as routers
    networks_per_router: 1

    # Number of VM instances to be created within the context of each Network
    vms_per_network: 1

    # Number of security groups per network
    secgroups_per_network: 1

    # Assign floating IP for every server side test VM
    # Default: no floating IP (only assign internal fixed IP)
    use_floatingip: False

    # Traffic shaping - VM Placement hint
    # Availability zone to use for servers in the server cloud
    # Leave empty if you prefer to have the Nova scheduler place the server VMs
    # If you want to pick a particular AZ, put that AZ name (e.g. nova)
    # If you want a paticular compute host, put the AZ and compute host names
    # separated by ':' (e.g. nova:tme100)
    # Note that this is ignored/overriden if you specify a topology file (-t)
    availability_zone:

    # HTTP Server specific configs (per VM)
    http_server_configs:
        # The size of HTML page in Bytes
        html_size: 32768


# ==========================
# CLIENT SIDE CONFIG OPTIONS
# ==========================
client:
    # Progression testing configuration
    # If enabled, KloudBuster will give multiple runs (progression) on the cloud,
    # unless it reaches the scale defined in the upper sections, or the stop limit.
    progression:
        # Enable/Disable the progression
        enabled: False
        # The starting count of VMs
        vm_start: 1
        # The steping for the VM count for each stage
        vm_step: 1
        # The stop condition, it is used for KloudBuster to determine when to
        # stop the progression, and do the cleanup if needed. It defines as:
        # [number_of_socket_errs, percentile_of_requests_not_timeout(%%)]
        #
        # e.g. [50, 99.99] means, KloudBuster will continue the progression run
        #   only if *ALL* below conditions are satisfied:
        #   (1) The socket error count (including errors and timeouts) is less
        #       or equal than 50;
        #   (2) 99.99%% of the requests are within the timeout range;
        #
        # Note:
        #   (1) The HTTP request timeout value is defined in the
        #       client:http_tool_config section;
        #   (2) The percentile of requests must be in the below list:
        #       [50, 75, 90, 99, 99.9, 99.99, 99.999]
        #   (3) Sets percentile to 0 to disable HTTP request timeout checks;
        stop_limit: [50, 0]

    # Assign floating IP for every client side test VM
    # Default: no floating IP (only assign internal fixed IP)
    use_floatingip: False

    # Flavor to use for the test images
    flavor:
        # Number of vCPUs for the flavor
        vcpus: 1
        # Memory for the flavor in MB
        ram: 2048
        # Size of local disk in GB
        disk: 20

    # Traffic shaping - VM Placement hint
    # Availability zone to use for clients in the client cloud
    # Leave empty if you prefer to have the Nova scheduler place the server VMs
    # If you want to pick a particular AZ, put that AZ name (e.g. nova)
    # If you want a paticular compute host, put the AZ and compute host names
    # separated by ':' (e.g. nova:tme100)
    # Note that this is ignored/overriden if you specify a topology file (-t)
    availability_zone:

    # Interval for polling status from all VMs in seconds
    polling_interval: 5

    # HTTP tool specific configs (per VM)
    # Every HTTP server VM is paired to 1 HTTP traffic generator VM
    # KloudBuster will take care of setting up the proper static routes
    # to allow connectivity between all pairs of VMs.
    # For example, if 1000 HTTP servers are configured, KloudBuster will
    # instantiate 1000 HTTP traffic generators and match them 1:1, for a total
    # of 2000 VM instances.
    http_tool_configs:
        # Threads to run tests
        threads: 1
        # Connections to be kept concurrently per VM
        # This number also corresponds to the number of HTTP users
        # connected at any time to the matching HTTP server
        connections: 1000
        # Rate limit in RPS per client (0 for unlimited)
        rate_limit: 1000
        # Timeout for socket connections
        timeout: 5
        # Connection Type: "Keep-alive", "New"
        # Keep-alive: the TCP connection is reused across requests
        # New: create a new TCP connection for every request (and close it after receiving the reply)
        # NOTE: "New" is not currently supported.
        connection_type: 'Keep-alive'
        # Interval for periodical report in seconds
        # Use 0 if you only need 1 final aggregated report for the entire run duration
        # Otherwise will provide results at every interval (results are reset
        # at the start of each period and are not cumulative across periods)
        report_interval: 0
        # Duration of testing tools (seconds)
        duration: 30

    # Prompt before running benchmarking tools
    prompt_before_run: False