Glossary of Terms
Application. A coherent instance of a piece of software, which may be a cluster of units or a single unit. For example, in a deployment of Hadoop there may be several different machines running the HDFS software, which together appear to the outside world to be a single coherent instance.
Charm. A package of operator code, usable on a machine or Kubernetes substrate.
Counterpart. A unit of the application across a relation.
Epoch. A generation of charm versions that is compatible with particular local data storage. Over time, a charm author may decide to change the way it stores local data – for example, it might switch from a flat file configuration to a key‐value database for resiliency, and those would then be two generations – epochs – of the charm. A charm can support multiple epochs, and this provides the mechanism for upgrades over epochs. The deployment will be upgraded to the newest charm that supports both its current epoch and the next epoch, so that conversions can take place, before upgrading to the newest charm of the next epoch.
Juju. The lifecycle manager for operators, which handles event delivery and responds to model changes from administrators.
Operator Lifecycle Manager. The model‐driven operator modelling and event distribution system which coordinates activity across multiple operators in a single model.
Peer. A unit of the same application as this one.
Relation. A line of integration between two applications, defined by the endpoints on each application which must have matching type, with one being inbound and the other outbound.
Unit. A single instantiation of a piece of software. For example, in a high‐availability database, it would be common to have two units, one of which is active and the other a standby. Together, those two units form the application.
Workload. The application that is driven by the operator.