Service Providers

Configuration

Each provider has its own configuration file that provides all the information to access and use the provider plus the configuration of the services offered by the provider (e.g. VM creation). The configuration is specified in a properties file (also in JSON format). The list of supported properties is shown below (see on GitHub [1]):

#
# PROVIDER SECTION
#
#

[provider]

#
# MANDATORY FIELDS
#

# the Benchmarking Suite class that implement the access to this provider
class = benchsuite.stdlib.provider.libcloud.LibcloudComputeProvider

# custom human-readable name for the provider. Used only for displaying purposes
name = ote-testbed

# the driver that Libcloud should use to access the provider
driver = openstack

# Access credentials
access_id = admin
secret_key = xxxxx

# Authentication URL for the target Cloud
auth_url = http://cloudpcntlr:5000/


#
# OPTIONAL FIELDS
#

# If not specified RegionOne is used
region = RegionOne

# if not specified 2.0_password and 3.x_password will be attempted
auth_version = 3.x_password

# if not specified, a new security group "benchsuite_sg" will be created (if
# not exist)
security_group = mysg

# Automatically selected if multiple exist
network = mynet

# If not specified the access_id is used
tenant = admin

# If specified do not attemp to assign a public IP
benchsuite.openstack.no_floating_ip = true


# after a new VM is created, a connection test is executed to check that everything
# is ok and to execute the post-creation scripts.
new_vm.connection_retry_period = 30
new_vm.connection_retry_times = 10


#
# SERIVCE TYPE SECTIONS
#
#

[ubuntu_large]

#
# MANDATORY FIELDS
#

image = base_ubuntu_14.04
size = m1.large


#
# OPTIONAL FIELDS
#

# name of the keypair to assign to the VM. If not specified, a new keypair will
# be created and then removed after the test ends.
key_name = ggiammat-key

# file that contains the private key. Alternatively the private key can be
# specified in this config file directly with the ssh_private_key property
key_path = /home/ggiammat/credentials/filab-vicenza/ggiammat-key.pem

# optional way to specify the key directly in the configuration instead
# of by filename
ssh_private_key = -----BEGIN RSA PRIVATE KEY-----
    MIIEowIBAAKCAQEAkadPr5n1NSOyHloajvovCD05M5Gz36NN4UouSWmId8QuTwXx
    Hw6m9aOXJmYHdkSYLrNs+y65EDpUkw1DXNDEJ146ZK9PxAQEdcngwPk76a4A/ybz
    [...]
    x+GRpQ9o/4EAzpBw9NVNNJ9Glbd7SSFqhpHR5pn5OBG/fdPJV8DzjUET528o8Jd9
    gynGwAYRed38UtCE7gn+u1RSvmYUveDwQ7Cf2KIohI2jlzR6YLea
    -----END RSA PRIVATE KEY-----

# If not specified, the Benchmarking Suite will try to guess them
vm_user = ubuntu
platform = ubuntu

# any command to run just after the VM has been created
post_create_script =
    sudo hostname localhost

Managing service providers through the GUI

This functionality allows the registration of cloud service accounts you own, on top of which benchmarks are to be executed.

Besides basic metadata (e.g. name and description) Cloud services are characterized by a set of connection parameters required to create ephemeral virtual machines to support benchmarking sessions.

Regardless of the type of benchmark that will be executed, VMs might need to be configured just after the provisioning process; to this end, the Cloud Services Management allows the definition of custom commands to be executed on the target VM, also supporting the differentiation among target OS (e.g. CentOS, Ubuntu, Ubuntu_18, Ubuntu_20, etc.).

Supported Cloud technologies include OpenStack, VMWare vCloud and Amazon EC2.

From the ‘Providers’ panel, a new service provider can be added via the ‘New Provider’ button which shows a form asking for a few provider metadata.

Similarly, once a provider has been selected, it can be modified, cloned into a new one or deleted (provided you have enough permissions on it).

Provider metadata

  • Provider name is a name, not necessarily unique, given to the provider;
  • Provider ID is a unique identifier provided by the system, and is not modifiable;

Connection metadata

This section contains coordinates needed to connect to the service provider in order to create virtual machines. The exact set of metadata depends on the selected cloud technology:

OpenStack
  • Authentication method
  • Authentication URL
  • Tenant name
  • Region
  • Domain
  • Username
  • Password
VMWare
  • Host
  • Organization
  • VDC
  • Username
  • Password
Amazon EC2
  • Region
  • Username
  • Password

Service accounts

This section contains credentials to access services (i.e. VMs).

The base property names for credentials are ‘vm_user’ and ‘vm_password’. But os-specific credentials can be set by suffixing the properties with os name/version (e.g. ‘vm_user_debian’, ‘vm_user_debian_10’, ‘vm_user_debian_10_9’, …)

Post-create scripts

Post-create scripts are executed after the provisioning of the virtual machine to perform some general initialization (e.g. configure the DNS).

As with service accounts, OS-specific scripts can be set through naming mechanism, like in the following example:

  • debian_10_8: post-install script to execute on Debian 10.9 VMs
  • debian: post-install script to execute on any other Debian VM
  • centos: post-install script to execute on any CentOS VM
  • default: post-install script to execute on any VMs

Additional scripts can also be defined to be used within the above ones (to define some action to be taken for multiple platforms, e.g. configure_dns).

Custom properties

Depending on the provider technology, additional connection properties might be needed; they can be set here.

Additionally, properties set here can be referenced within post-create scripts.

Sharing

Cloud services are always kept private to their owner, although some general metadata (e.g. name and description) might appear along with associated metrics if these are shared to an organization or made public.

[1]https://github.com/benchmarking-suite/benchsuite-stdlib/blob/master/data/providers/openstack.conf.example