Glossary#
Definitions for terms used in Kiso documentation, including Kiso-specific terms, testbed terminology, and HTCondor terminology.
Kiso terms#
Component One of the four categories of Kiso components: Testbed, Software, Deployment, or Experiment type. Components are combined in a config file to describe an experiment.
Config file A YAML file that describes an experiment completely: resources, software, deployment, and experiment steps. The single source of truth for a Kiso experiment.
Experiment
A defined set of steps to execute on provisioned resources. Described in the experiments section of the config file.
Label
A user-defined string assigned to one or more machines in the sites section. Used to target machines in the software, deployment, and experiments sections. The connective tissue between config sections.
Output directory
The local directory (default: output/) where Kiso writes environment state and experiment results. Specified with --output.
Plugin A Python package registered via entry points that adds a new component (software, deployment, or experiment type) to Kiso.
Site
An infrastructure provider entry in the sites config section. A single experiment can have multiple sites.
Testbed portability Kiso’s design goal: the same config file should run on any supported testbed with minimal changes.
Testbed terms#
FABRIC#
Bastion host A gateway node through which users SSH to access FABRIC nodes. FABRIC nodes are not directly accessible from the internet; all connections go through the bastion.
Fabric token A credential token downloaded from the FABRIC portal, used to authenticate API calls for provisioning resources.
Floating IP A public IP address that can be attached to a FABRIC, Chameleon, or Chameleon Edge node, making it reachable from the internet. Required for HTCondor submit/central-manager nodes in multi-testbed deployments.
Site (FABRIC)
A FABRIC data centre location. FABRIC has sites at multiple universities and research institutions. Not to be confused with Kiso’s sites config section.
Slice A FABRIC resource reservation containing nodes, networks, and other components. Kiso creates and manages slices on your behalf.
Chameleon#
Bare metal Physical servers allocated to a single user, providing dedicated hardware resources. Chameleon’s primary resource model.
Chameleon Edge A separate Chameleon site (CHI@Edge) that provides IoT and edge hardware (Raspberry Pis, Jetson devices, and others) as container-based resources. Chameleon Edge uses the same Chameleon project allocation as Chameleon Cloud, but requires its own site-specific OpenRC credentials file — a CHI@UC or CHI@TACC credential file will not work with CHI@Edge.
Lease A Chameleon or Chameleon Edge resource reservation. Has a start time, end time (walltime), and specifies which hardware to reserve. Kiso creates leases on your behalf.
OpenRC file A shell script downloaded from the Chameleon dashboard that sets environment variables for OpenStack API authentication. Required by Kiso for Chameleon access.
Walltime
The duration of a Chameleon lease. Specified in HH:MM:SS format. Resources are released when the walltime expires.
Vagrant#
Box A Vagrant base image (pre-configured OS image). Kiso selects the appropriate box automatically.
Flavour
A predefined VM size: small (1 vCPU, 1 GB), medium (2 vCPU, 2 GB), or large (4 vCPU, 4 GB).
Provider The virtualization backend Vagrant uses to create VMs. Kiso uses VirtualBox.
HTCondor terms#
Central manager The HTCondor daemon responsible for matchmaking — tracking which execute nodes are available and which jobs are waiting. Must have a public IP in multi-testbed deployments.
ClassAd A key-value structure used by HTCondor to describe jobs and resources. The matchmaker matches job requirements ClassAds to machine ClassAds.
Condor pool The set of all HTCondor nodes (submit, central manager, and execute) that share a central manager. Kiso creates a pool per experiment.
Execute node A node in the HTCondor pool that runs individual tasks. Can exist on multiple testbeds in a multi-testbed deployment.
Personal HTCondor A single-machine HTCondor setup where one node runs all daemons (central manager, submit, and execute). Used for simple experiments.
Submit node The node from which jobs are submitted to HTCondor. Also called the access point. Must have a public IP in multi-testbed deployments.
Trust domain
The security domain for an HTCondor pool. Kiso uses kiso.scitech.isi.edu as the trust domain for all pools it creates.
Workflow and experiment terms#
DAG (Directed Acyclic Graph) A workflow structure where tasks are nodes and dependencies are directed edges. Used by Pegasus to represent experiment workflows with task ordering constraints.
Pegasus A workflow management system that maps abstract workflow DAGs to concrete jobs submitted to HTCondor. Used for complex multi-step experiments with task dependencies.
Provenance A record of what was run, with what inputs, on what resources, and when. Pegasus automatically captures provenance for all workflow executions.
Shell experiment A Kiso experiment type that runs shell scripts on targeted nodes. The simplest experiment type.
Workflow In the context of Pegasus: a DAG of computational tasks submitted to HTCondor for execution.
See also#
What is Kiso? — introduction to Kiso concepts
Components — detailed explanation of each component type
Config file anatomy — how terms map to config structure