# 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
# =====================================================

# The openrc file - can be overridden at the cli with the --rc argument
openrc_file:

# Name of the image to use for all test VMs (client, server and proxy)
# without the qcow2 extension
# 
# 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')
# The default test VM image is named "kloudbuster-<version>" where
# <version> is the KloudBuster version (e.g. "kloudbuster-7.0.0")
image_name:

# KloudBuster can automatically upload a VM image if the image named by
# image_name is missing, for that you need to specify a file location where
# the image can be retrieved
#
# To upload the image, download it first to a local file system before running kloudbuster
# Fill with the full pathname of the image with qcow2 extension
# e.g. 
# vm_image_file: /kloudbuster/kloudbuster-7.0.0.qcow2
# If empty, KloudBuster will attempt to locate that file (with the default name) 
# under the following directories:
# - root of the kloudbuster package
# - current directory
vm_image_file:

# 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:

# Name of Provider network used for multicast tests.
multicast_provider_network_name: '' # Leave blank to use first available (default) network.


# ==================================================
# SERVER SIDE CONFIG OPTIONS (HTTP SERVER SIDE ONLY)
# ==================================================
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: 0

    # 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/overridden if you specify a topology file (-t)
    availability_zone:

    # 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

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


# ====================================================
# CLIENT SIDE CONFIG OPTIONS (HTTP CLIENT AND STORAGE)
# ====================================================
client:
    # 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: 0
        # metadata are supported and can be added if needed
        # example:
        #extra_specs: 
            #"hw:cpu_policy": dedicated

    # Assign floating IP for every client 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 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/overridden if you specify a topology file (-t)
    availability_zone:

    # 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:
        #     0: Start directly from vm_multiple;
        #     1: Start from 1 VM;
        vm_start: 1
        # The steping for the VM count for each stage
        # e.g. KloudBuster will run iterations on below sequences:
        #      {'vm_start': 1, 'vm_multiple': 2}: 1, 2, 4, 6, 8...    [DEFAULT]
        #      {'vm_start': 1, 'vm_multiple': 5}: 1, 5, 10, 15, 20...
        #      {'vm_start': 0, 'vm_multiple': 1}: 1, 2, 3, 4, 5...
        #      {'vm_start': 0, 'vm_multiple': 5}: 5, 10, 15, 20...
        vm_multiple: 2

        # HTTP ONLY
        # The stop condition for HTTP benchmarking, 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;
        http_stop_limit: [50, 0]

        # STORAGE ONLY
        # The stop condition for storage benchmarking, it is used for KloudBuster
        # to determine when to stop the progression, and do the cleanup if needed.
        # In the mode of random read and random write, this value indicates the
        # percentile of degrading on IOPS, while in the mode of sequential read
        # and sequential write, this value indicates the percentile of degrading
        # on throughput.
        #
        # Assume the IOPS or throughput per VM is a fixed value, usually we are
        # expecting higher values when the VM count grows. At certain point where
        # the capacity of storage is reached, the overall performance will start
        # to degrade.
        #
        # e.g. In the randread and randwrite mode, for example the IOPS is limited
        # to 100 IOPS/VM. In the iteration of 10 VMs, the requested IOPS for the
        # system is 100 * 10 = 1000. However, the measured IOPS is degraded to
        # only 800 IOPS. So the degraded percentile is calculated as 800/1000=20%
        # for this set of data.
        #
        # KloudBuster will continue the progression run if the degrading percentile
        # is within (less or equal) the range defined below.
        storage_stop_limit: 20

    # 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


    # Multicast Test Mode Configurations.
    multicast_tool_configs:
        multicast_address_start: '231.0.0.1' # No need to change this.
        # Two main test modes: 1) Internal sender -> Internal receivers (default)
        # 2) External Sender -> Internal Receivers (specified by setting external_sender_test_mode: True)
        # Requires a reachable external host with nuttcp installed in server mode at external_sender
        # listening at external_sender_port. It should sync with the same ntp_clocks if possible.
        external_sender_test_mode: False
        external_sender: '0.0.0.0'
        external_sender_port: 5200
        # Configs for both test modes
        receivers: [1]  # Number of multicast listener VMs to create.
        addresses: [1,2]  # Number of multicast groups to test.
        ports: [1,5]    # Number of multicast ports to use per address.
        pktsizes: [64, 1316, 4096, 9000]  # in kb
        bitrates: [ 0.1, 1, 10, 100, 270, 500, 1000, 1500, 3000, 10000] #in Mbps
        # The below patterns define the address : port relationship in the tests.
        # Each entry is a test case. Test_i: (address_test_pattern[i],port_test_pattern[i])
        # Make sure len(address_test_pattern) == len(port_test_pattern)
        address_test_pattern: [1,1,2,2]
        port_test_pattern: [1,5,1,5]
        # NTP clocks close to the cloud are required for precise latency results.
        # Any machine running NTP in server mode can be used.
        ntp_clocks: ["0.north-america.pool.ntp.org", "1.north-america.pool.ntp.org"]  # The closer the better.
        # Time in seconds for each test case. Best kept between 4-8 seconds.
        duration: 4


    # Storage specific configs during staging phase
    # Will effect only in storage testing mode.
    storage_stage_configs:
        # The number of VMs for running storage tests
        vm_count: 1
        # KloudBuster supports to run storage tests on Cinder Volumes or Ephemeral
        # Disks. Available options to be configured: ['volume', 'ephemeral'].
        target: 'volume'
        # Volumes size in GB for each VM
        disk_size: 10
        # The size of the test file for running IO tests in GB. Must be less or
        # equal than disk_size. Defaults to 1 GB
        io_file_size: 1

    # Storage tool specific configs (per VM)
    # Multiple factors can impact the storage performance numbers, and KloudBuster is defining
    # a default profile which consists of six testing scenarios:
    # (1) Random read
    # (2) Random write
    # (3) Random mixed read/write (70% read, 30% write)
    # (4) Sequential read
    # (5) Sequential write
    # (6) Sequential mixed read/write (70% read, 30% write)
    #
    # Accepted testing parameters for each scenario:
    # description: (Required)
    #     A string describing the test case
    # mode: (Required)
    #     Self-explained with the name, must be one of the below:
    #     ['randread', 'randwrite', 'randrw', 'read', 'write', 'rw']
    # runtime: (Required)
    #     Maximum test duration in seconds or 0 if unlimited
    # block_size: (Required, default=4k)
    #     Block size for I/O operations
    # iodepth: (Required, default=1)
    #     Number of I/O operations to keep in flight against the file
    # rate_iops: (Optional, default=unlimited)
    #     Cap the bandwidth to this number of IOPS for each VM
    #     This is a per VM cap.
    #     Omit or use 0 for unrestricted iops
    # rate: (Optional, default=unlimited)
    #     Cap the bandwidth to this number of bytes/sec for each VM, normal postfix rules apply
    #     This is a per VM cap.
    #     Omit or use 0 for unrestricted rate
    # rwmixread: (Required when mode is 'randrw' or 'rw')
    #     Percentage of a mixed workload that should be reads (a value between 0 and 100)
    # extra_opts: (Optional, default=None)
    #     Extra options that will be added verbatim to the FIO client
    storage_tool_configs:
        - description: 'Random Read'
          mode: 'randread'
          runtime: 30
          block_size: '4k'
          iodepth: 4
          rate_iops: 100
        - description: 'Random Write'
          mode: 'randwrite'
          runtime: 30
          block_size: '4k'
          iodepth: 4
          rate_iops: 100
        - description: 'Random Read/Write'
          mode: 'randrw'
          runtime: 30
          block_size: '4k'
          iodepth: 4
          rate_iops: 100
          rwmixread: 70
        - description: 'Sequential Read'
          mode: 'read'
          runtime: 30
          block_size: '64k'
          iodepth: 64
          rate: '60M'
        - description: 'Sequential Write'
          mode: 'write'
          runtime: 30
          block_size: '64k'
          iodepth: 64
          rate: '60M'
        - description: 'Sequential Read/Write'
          mode: 'rw'
          runtime: 30
          block_size: '64k'
          iodepth: 64
          rate: '60M'
          rwmixread: 70

    # Prompt before running benchmarking tools
    prompt_before_run: False
