bexhoma.configurations module

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

class bexhoma.configurations.benchbase(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: default

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object.

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)

Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to YCSB.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms

Returns:

Name of file in YAML format containing the benchmarker job

class bexhoma.configurations.default(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: object

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object.

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

OLD_get_items(app='', component='', experiment='', configuration='')

add_benchmark_list(list_clients)

Add a list of (number of) benchmarker instances, that are to benchmark the current SUT. Example: [1,2,1] means sequentially we will have 1, then 2 and then 1 benchmarker instances.

Parameters:: list_clients – List of (number of) benchmarker instances

add_benchmarking_parameters(**kwargs)

Sets ENV for benchmarking components. Can be set by experiment before creation of configuration. This generates a list, where each entry corresponds to a set of clients in a sequence of benchmarkers.

Parameters:: kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’

attach_worker(): Attaches worker nodes to the master of the sut. This runs the dockertemplate[‘attachWorker’] command.

check_DBMS_connection(ip, port)

Check if DBMS is open for connections. Tries to open a socket to ip:port. Returns True if this is possible.

Parameters:

ip – IP of the host to connect to
port – Port of the server on the host to connect to

Returns:

True, iff connecting is possible

check_load_data(): Check if loading of the sut has finished. If yes, store timeLoadingStart, timeLoadingEnd, timeLoading as labels and in this object as attributes. If there is a loading job: check if all pods are completed. Copy the logs of the containers in the pods and remove the pods. If there is no loading job: Read the labels. If loaded is True, store the timings in this object as attributes.

check_sut(): Check if the pod of the sut is running. If yes, store it’s name in self.pod_sut.

client: If we have a sequence of benchmarkers, this tells at which position we are

configuration: Name of the configuration, default: Name of the Docker image

connection_parameter: Collect all parameters that might be interesting in evaluation of results

copyLog()

create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', env={}, template='', num_pods=1)

Creates a job template for the benchmarker. This sets meta data in the template and ENV.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms
env – Dict of environment variables
template – Template for the job manifest

Returns:

Name of file in YAML format containing the benchmarker job

create_manifest_job(app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, env={}, template='', nodegroup='', num_pods=1, connection='', patch_yaml='')

Creates a job and sets labels (component/ experiment/ configuration).

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
experimentRun – Number of run of the configuration in this experiment
client – Number of client of the job for this experiment run
parallelism – Number of parallel pods in this job
env – Dict of environment variables for the job manifest
template – Template name of the job manifest
nodegroup – Nodegroup of the pods of the job
num_pods – Number of pods that run in total

create_manifest_loading(app='', component='loading', experiment='', configuration='', parallelism=1, alias='', num_pods=1, connection='')

Creates a job template for loading. This sets meta data in the template and ENV.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job

Returns:

Name of file in YAML format containing the loading job

create_manifest_maintaining(app='', component='maintaining', experiment='', configuration='', parallelism=1, alias='', num_pods=1, connection='')

Creates a job template for maintaining. This sets meta data in the template and ENV.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job

Returns:

Name of file in YAML format containing the maintaining job

create_monitoring(app='', component='monitoring', experiment='', configuration='')

Generate a name for the monitoring component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

delay(sec, silent=False)

Function for waiting some time and inform via output about this. Synonymous for wait()

Parameters:

sec – Number of seconds to wait
silent – True means we do not output anything about this waiting

docker: Name of the Docker image

dockerimage: Name of the Docker image of the SUT

dockertemplate: Template of the Docker information taken from cluster.config

execute_command_in_pod_sut(command, pod='', container='dbms', params='')

Runs an shell command remotely inside a container of a pod. This defaults to the current sut’s pod and the container “dbms”

Parameters:

command – A shell command
pod – The name of the pod - default current sut’s pod
container – The name of the container in the pod - default dbms
params – Optional parameters, currently ignored

Returns:

stdout of the shell command

experiment: Unique identifier of the experiment

experiment_done: True, iff the SUT has performed the experiment completely

generate_component_name(app='', component='', experiment='', configuration='', experimentRun='', client='')

Generate a name for the component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of the client, if it comes from a sequence of same components (in particular benchmarker)

getTimediff()

get_connection_config(connection, alias='', dialect='', serverip='localhost', monitoring_host='localhost')

Returns information about the sut’s host disk space. Basically this calls df / on the host.

Returns:: Size of disk in Bytes

get_host_all()

Calls all get_host_x() methods. Returns information about the sut’s host as a dict.

Returns:: Dict of informations about the host

get_host_cores()

Returns information about the sut’s host CPU’s cores. Basically this calls grep -c ^processor /proc/cpuinfo on the host.

Returns:: CPU’s cores of the host

get_host_cpu()

Returns information about the sut’s host CPU. Basically this calls more /proc/cpuinfo | grep ‘model name’ on the host.

Returns:: CPU of the host

get_host_cuda()

Returns information about the sut’s host CUDA version. Basically this calls nvidia-smi | grep ‘CUDA’ on the host.

Returns:: CUDA version of the host

get_host_diskspace_used()

Returns information about the sut’s host disk space. Basically this calls df / on the host.

Returns:: Size of disk in Kilobytes

get_host_diskspace_used_data()

Returns information about the sut’s host disk space used for the data (the database) in kilobyte. Basically this calls du on the host directory that is mentioned in cluster.config as to store the database.

Returns:: Size of disk used for database in Kilobytes

get_host_gpu_ids()

Returns information about the sut’s host GPUs. Basically this calls nvidia-smi -L on the host and generates a list of UUIDs of the GPUs.

Returns:: List of GPU UUIDs of the host

get_host_gpus()

Returns information about the sut’s host GPUs. Basically this calls nvidia-smi -L on the host and aggregates result.

Returns:: GPUs of the host

get_host_memory()

Returns information about the sut’s host RAM. Basically this calls grep MemTotal /proc/meminfo on the host.

Returns:: RAM of the host

get_host_node()

Returns information about the sut’s host name. Basically this calls kubectl get pod to receive the information.

Returns:: Node name of the host

get_host_system()

Returns information about the sut’s host OS. Basically this calls uname -r on the host.

Returns:: OS of the host

get_instance_from_resources()

Generates an instance name out of the resource parameters that are set using set_resources(). Should be DEPRECATED and replaced by something better.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

get_patched_yaml(file, patch='')

Applies a YAML formatted patch to a YAML file and returns merged result as a YAML object.

Parameters:

file – Name of YAML file to load
patch – Optional patch to be applied

Returns:

YAML object of (patched) file content

get_service_sut(configuration)

Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten.

Parameters:: configuration – name of the configuration
Returns:: name of the configuration’s sut’s service

get_worker_endpoints()

Returns all endpoints of a headless service that monitors nodes of a distributed DBMS. These are IPs of cAdvisor instances. The endpoint list is to be filled in a config of an instance of Prometheus. By default, the workers can be found by the name of their component (worker-0 etc).

Returns:: list of endpoints

get_worker_pods()

load_data(scripts, time_offset=0, time_start_int=0, script_type='loaded'): Start loading data into the sut. This runs load_data_asynch() as an asynchronous thread. At first prepare_init_dbms() is run.

loading_after_time: Time as an integer when initial loading should start - to give the system time to start up completely

loading_finished: Time as an integer when initial loading has finished

loading_started: Time as an integer when initial loading has started

maintaining_is_pending()

Returns True, iff maintaining is in pending state.

Returns:: True, if maintaining is in pendig state

maintaining_is_running()

Returns True, iff maintaining is running.

Returns:: True, if dbms is running

monitor_loading: Fetch metrics for the loading phase, if monítoring is active - this is set to False when loading is skipped due to PV

monitoring_is_pending()

Returns True, iff monitoring is in pending state.

Returns:: True, if monitoring is in pendig state

monitoring_is_running()

Returns True, iff monitoring is running.

Returns:: True, if monitoring is running

patch_benchmarking(patch)

Patches YAML of loading components. Can be set by experiment before creation of configuration.

Parameters:: patch – String in YAML format, overwrites basic YAML file content

patch_loading(patch)

Patches YAML of loading components. Can be set by experiment before creation of configuration.

Parameters:: patch – String in YAML format, overwrites basic YAML file content

pod_sut: Name of the sut’s master pod

prepare_init_dbms(scripts): Prepares to load data into the dbms. This copies the DDL scripts to /tmp on the host of the sut. Optionally parameters in DDL script are replaced by ddl_parameters. The files are renamed filled_ then.

reset_sut(): Forget that the SUT has been loaded and benchmarked.

run_benchmarker_pod(connection=None, alias='', dialect='', query=None, app='', component='benchmarker', experiment='', configuration='', client='1', parallelism=1)

Runs the benchmarker job. Sets meta data in the connection.config. Copy query.config and connection.config to the first pod of the job (result folder mounted into every pod)

Parameters:

connection – Name of configuration prolonged by number of runs of the sut (installations) and number of client in a sequence of
alias – An alias can be given if we want to anonymize the dbms
dialect – A name of a SQL dialect can be given
query – The benchmark can be fixed to a specific query
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker this is in a sequence of
parallelism – Number of parallel benchmarker pods we want to have

set_additional_labels(**kwargs)

Sets additional labels, that will be put to K8s objects (and ignored otherwise). This is for the SUT component. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of labels, example ‘SF’ => 100

set_benchmarking_parameters(**kwargs)

Sets ENV for benchmarking components. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’

set_connectionmanagement(**kwargs)

Sets connection management data for the experiment. This is for the benchmarker component (dbmsbenchmarker). Can be overwritten by configuration.

Parameters:: kwargs – Dict of meta data, example ‘timout’ => 60

set_ddl_parameters(**kwargs)

Sets DDL parameters for the experiments. This substitutes placeholders in DDL script. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘index’ => ‘btree’

set_eval_parameters(**kwargs)

Sets some arbitrary parameters that are supposed to be handed over to the benchmarker component. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘type’ => ‘noindex’

set_experiment(instance=None, volume=None, docker=None, script=None, indexing=None): Read experiment details from cluster config

set_loading(parallel, num_pods=None)

Sets job parameters for loading components: Number of parallel pods and optionally (if different) total number of pods. By default total number of pods is set to number of parallel pods. Can be set by experiment before creation of configuration.

Parameters:

parallel – Number of parallel pods
num_pods – Optionally (if different) total number of pods

set_loading_parameters(**kwargs)

Sets ENV for loading components. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’

set_maintaining(parallel, num_pods=None)

Sets job parameters for maintaining components: Number of parallel pods and optionally (if different) total number of pods. By default total number of pods is set to number of parallel pods. Can be set by experiment before creation of configuration.

Parameters:

parallel – Number of parallel pods
num_pods – Optionally (if different) total number of pods

set_maintaining_parameters(**kwargs)

Sets ENV for maintaining components. Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’

set_metric_of_config(metric, host, gpuid)

Returns a promql query. Parameters in this query are substituted, so that prometheus finds the correct metric. Example: In ‘sum(irate(container_cpu_usage_seconds_total{{container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_container_name=”dbms”}}[1m]))’ configuration and experiment are placeholders and will be replaced by concrete values.

Parameters:

metric – Parametrized promql query
host – Name of the host the metrics should be collected from
gpuid – GPU that the metrics should watch

Returns:

promql query without parameters

set_nodes(**kwargs)

set_resources(**kwargs)

Sets resources for the experiment. This is for the SUT component. Can be overwritten by experiment and configuration.

Parameters:: kwargs – Dict of meta data, example ‘requests’ => {‘cpu’ => 4}

set_storage(**kwargs)

Sets parameters for the storage that might be attached to components. This is in particular for the database of dbms under test. Example:

storageClassName = ‘ssd’, storageSize = ‘100Gi’, keep = False

Can be set by experiment before creation of configuration.

Parameters:: kwargs – Dict of meta data, example ‘storageSize’ => ‘100Gi’

start_loading(delay=0)

Starts data ingestion by calling scripts inside the sut (dbms) container.

Parameters:: delay – Number of seconds to wait after calling scripts

start_loading_pod(app='', component='loading', experiment='', configuration='', parallelism=1, num_pods=1)

Starts a job for parallel data ingestion.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job

start_maintaining(app='', component='maintaining', experiment='', configuration='', parallelism=1, num_pods=1)

Starts a maintaining job.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job

start_monitoring(app='', component='monitoring', experiment='', configuration='')

Starts a monitoring deployment.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

start_sut(app='', component='sut', experiment='', configuration='')

Start the system-under-test (dbms). This also controls optional worker and storage. Resources are set according to set_resources().

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

stop_loading(app='', component='loading', experiment='', configuration='')

Stops a loading job and removes all its pods.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

stop_maintaining(app='', component='maintaining', experiment='', configuration='')

Stops a monitoring deployment and removes all its pods.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

stop_monitoring(app='', component='monitoring', experiment='', configuration='')

Stops a monitoring deployment and removes its service.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

stop_sut(app='', component='sut', experiment='', configuration='')

Stops a sut deployment and removes all its services and (optionally) stateful sets. It also stops and removes all related components (monitoring, maintaining, loading).

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

sut_is_pending()

Returns True, iff system-under-test (dbms) is in pending state.

Returns:: True, if dbms is in pendig state

sut_is_running()

Returns True, iff system-under-test (dbms) is running.

Returns:: True, if dbms is running

timeGenerating: Time in seconds the system has taken for generating the data

timeIndex: Time in seconds the system has taken for indexing the database

timeIngesting: Time in seconds the system has taken for ingesting existing

timeLoading: Time in seconds the system has taken for the initial loading of data

timeSchema: Time in seconds the system has taken for creating the db schema

use_distributed_datasource: True, iff the SUT should mount ‘benchmark-data-volume’ as source of (non-generated) data

use_storage(): Return True, iff storage for the database should be used. Otherwise database is inside ephemeral-storage.

wait(sec, silent=False)

Function for waiting some time and inform via output about this

Parameters:

sec – Number of seconds to wait
silent – True means we do not output anything about this waiting

class bexhoma.configurations.hammerdb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: default

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object.

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)

Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to HammerDB.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms

Returns:

Name of file in YAML format containing the benchmarker job

class bexhoma.configurations.kinetica(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: default

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object. This class contains specific settings for a Kinetica installation. This is handled outside of bexhoma with the official KAgent. The service name is fixed to be “bexhoma-service-kinetica”

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

create_monitoring(app='', component='monitoring', experiment='', configuration='')

Generate a name for the monitoring component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}. For Kinetica, the service to be monitored is named ‘bexhoma-service-kinetica’.

Parameters:

app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration

get_service_sut(configuration)

Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten. Here, always “bexhoma-service-kinetica” is returned.

Parameters:: configuration – name of the configuration
Returns:: name of the configuration’s sut’s service

get_worker_endpoints()

Returns all endpoints of a headless service that monitors nodes of a distributed DBMS. These are IPs of cAdvisor instances. The endpoint list is to be filled in a config of an instance of Prometheus. For Kinetica the service is fixed to be ‘bexhoma-service-monitoring-default’ and does not depend on the experiment.

Returns:: list of endpoints

set_metric_of_config(metric, host, gpuid)

Returns a promql query. Parameters in this query are substituted, so that prometheus finds the correct metric. Example: In ‘sum(irate(container_cpu_usage_seconds_total{{container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_container_name=”dbms”}}[1m]))’ configuration and experiment are placeholders and will be replaced by concrete values. Here: We do not have a SUT that is specific to the experiment or configuration.

Parameters:

metric – Parametrized promql query
host – Name of the host the metrics should be collected from
gpuid – GPU that the metrics should watch

Returns:

promql query without parameters

bexhoma.configurations.load_data_asynch(app, component, experiment, configuration, pod_sut, scriptfolder, commands, loadData, path, volume, context, service_name, time_offset=0, time_start_int=0, script_type='loaded')

class bexhoma.configurations.ycsb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: default

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object.

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)

Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to YCSB.

Parameters:

app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms

Returns:

Name of file in YAML format containing the benchmarker job

class bexhoma.configurations.yugabytedb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')

Bases: default

Date:

2022-10-01

Version:

0.6.0

Authors:

Patrick K. Erdelt

Class for managing an DBMS configuation. This is plugged into an experiment object. This class contains specific settings for a YugabyteDB installation. This is handled outside of bexhoma with the official helm chart. The service name is fixed to be “yb-tserver-service”

param experiment:: Unique identifier of the experiment
param docker:: Name of the Docker image
param configuration:: Name of the configuration
param script:: Unique identifier of the experiment
param alias:: Unique identifier of the experiment

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.

get_service_sut(configuration)

Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten. Here, always “yb-tserver-service” is returned.

Parameters:: configuration – name of the configuration
Returns:: name of the configuration’s sut’s service