Worker

In Juju, a worker is any type that implements the worker interface.

Examples of workers include the dependency engine, instances run by the dependency engine (the typical usage of the term “worker”), and watchers.

Note: A Juju agent runs one or more workers at the same time in parallel. A worker may run / be run by another worker.

Contents:

List of workers run by the dependency engine

List of workers run by the dependency engine

In Juju, the term “worker” is most commonly used to denote types whose instances are run by the dependency engine. These types are defined by the worker packages listeds below.

The most important workers to know about are: the uniter, the deployer, the provisioner, and the caasapplicationprovisioner, the charmdownloader, and the undertaker.

actionpruner
agent
agentconfigupdater
apiaddressupdater
apicaller
apiconfigwatcher
apiserver
apiservercertwatcher
applicationscaler
auditconfigupdater
authenticationworker
caasadmission
caasapplicationprovisioner
caasbroker
caasenvironupgrader
caasfirewaller
caasfirewallersidecar
caasmodelconfigmanager
caasmodeloperator
caasoperator
caasoperatorprovisioner
caasprober
caasrbacmapper
caasunitprovisioner
caasunitsmanager
caasunitterminationworker
caasupgrader
centralhub
certupdater
changestream
charmdownloader
charmrevision
cleaner
common
containerbroker
controllerport
credentialvalidator
dbaccessor
deployer
diskmanager
environ
environupgrader
externalcontrollerupdater
fanconfigurer
filenotifywatcher
firewaller
fortress
gate
hostkeyreporter
httpserver
httpserverargs
identityfilewriter
instancemutater
instancepoller
introspection
leadership
lease
leaseexpiry
lifeflag
logforwarder
logger
logsender
machineactions
machiner
machineundertaker
meterstatus
metrics
metricworker
migrationflag
migrationmaster
migrationminion
minunitsworker
mocks
modelcache
modelworkermanager
multiwatcher
muxhttpserver
peergrouper
presence
provisioner
proxyupdater
pruner
pubsub
querylogger
reboot
remoterelations
retrystrategy
s3caller
secretbackendrotate
secretdrainworker
secretexpire
secretrotate
simplesignalhandler
singular
state
stateconfigwatcher
stateconverter
statushistorypruner
storageprovisioner
syslogger
terminationworker
toolsversionchecker
undertaker
unitassigner
uniter
upgradedatabase
upgrader
upgradeseries
upgradesteps

`agentconfigupdater`

See more: juju/worker/agentconfigupdater

`apiaddressupdater`

The apiaddressupdater worker watches and stores the controllers’ addresses.

See more: juju/worker/apiaddressupdater

`apiconfigwatcher`

See more: juju/worker/apiconfigwatcher

`apiservercertwatcher`

See more: juju/worker/apiservercertwatcher

`applicationscaler`

See more: juju/worker/applicationscaler

`auditconfigupdater`

See more: juju/worker/auditconfigupdater

`authenticationworker`

See more: juju/worker/authenticationworker

`caasapplicationprovisioner`

The caasapplicationprovisioner worker is actually two workers:

provisioner: Watches a Kubernetes model and starts a new worker of the appWorker type whenever an application is created.
appWorker: Drives the Kubernetes provider to create, manage, and destroy Kubernetes resources to match a requested state. Also writes the state of created resources (application/unit status, application/unit IP addresses & ports, filesystem info, etc.) back into the database.

See more: juju/worker/caasapplicationprovisioner

`caasenvironupgrader`

See more: juju/worker/caasenvironupgrader

`caasfirewallersidecar`

See more: juju/worker/caasfirewallersidecar

`caasmodelconfigmanager`

See more: juju/worker/caasmodelconfigmanager

`caasmodeloperator`

See more: juju/worker/caasmodeloperator

`caasoperatorprovisioner`

See more: juju/worker/caasoperatorprovisioner

`caasunitprovisioner`

See more: juju/worker/caasunitprovisioner

`caasunitsmanager`

See more: juju/worker/caasunitsmanager

`caasunitterminationworker`

See more: juju/worker/caasunitterminationworker

The charm revision updater worker is responsible for polling Charmhub every 24 hours to check if there are new revisions available of any repository charm deployed in the model. If so, it will put a document in the Juju database, so that the next time the user runs juju status they can see that there is an update available. This worker also sends anonymised usage metrics to Charmhub when it polls.

This worker doesn’t contain much business logic - most of the work is delegated to the facade call.

See more: juju/worker/charmrevision

`cleaner`

The cleaner worker handles database clean-up events.

See more: juju/worker/cleaner

`common`

See more: juju/worker/common

`containerbroker`

The containerbroker worker’s sole responsibility is to manage the lifecycle of an instance-broker. Configuration of the instance-broker relies on talking to the provisioner to ensure that we correctly configure the correct availability zones. Failure to do so, will result in an error.

The instance-broker is created for LXD types only – any other container types cause the worker to uninstall itself.

See more: juju/worker/containerbroker

`controllerport`

See more: juju/worker/controllerport

`credentialvalidator`

See more: juju/worker/credentialvalidator

`dbaccessor`

See more: juju/worker/dbaccessor

`deployer`

See more: juju/worker/deployer

`diskmanager`

The diskmanager worker periodically lists block devices on the machine it runs on.

This worker will be run on all Juju-managed machines (one per machine agent).

See more: juju/worker/diskmanager

`environ`

See more: juju/worker/environ

`environupgrader`

See more: juju/worker/environupgrader

`externalcontrollerupdater`

See more: juju/worker/externalcontrollerupdater

`fanconfigurer`

See more: juju/worker/fanconfigurer

`filenotifywatcher`

See more: juju/worker/filenotifywatcher

`firewaller`

The firewaller worker modifies provider networks when a user exposes/de-exposes applications, or when a unit closes/opens ports.

See more: juju/worker/firewaller

`fortress`

The fortress worker implements a convenient metaphor for an RWLock.

A “fortress” is constructed via a manifold’s Start func, and accessed via its Output func as either a Guard or a Guest. To begin with, it’s considered to be locked, and inaccessible to Guests; when the Guard Unlocks it, the Guests can Visit it until the Guard calls Lockdown. At that point, new Visits are blocked, and existing Visits are allowed to complete; the Lockdown returns once all Guests’ Visits have completed.

The original motivating use case was for a component to mediate charm directory access between the uniter and the metrics collector. The metrics collector must be free to run its own independent hooks while the uniter is active; but metrics hooks and charm upgrades cannot be allowed to tread on one another’s toes.

See more: juju/worker/fortress

`gate`

The gate worker provides a mechanism by which independent workers can wait for one another to finish a task, without introducing explicit dependencies between those workers.

See more: juju/worker/gate

`hostkeyreporter`

See more: juju/worker/hostkeyreporter

`httpserver`

See more: juju/worker/httpserver

`httpserverargs`

See more: juju/worker/httpserverargs

`identityfilewriter`

See more: juju/worker/identityfilewriter

`instancemutater`

See more: juju/worker/instancemutater

`instancepoller`

The instancepoller worker updates network addresses and any related information for providers.

See more: juju/worker/instancepoller

`introspection`

See more: juju/worker/introspection

`leadership`

See more: juju/worker/leadership

`lease`

See more: juju/worker/lease

`leaseexpiry`

See more: juju/worker/leaseexpiry

`lifeflag`

See more: juju/worker/lifeflag

`logforwarder`

See more: juju/worker/logforwarder

`logger`

See more: juju/worker/logger

The logger worker watches the local logger configuration and reconfigures it when needed.

`logsender`

See more: juju/worker/logsender

`machineactions`

See more: juju/worker/machineactions

`machiner`

The machiner worker terminates the agent when the machine has a fatal error.

See more: juju/worker/machiner

`machineundertaker`

See more: juju/worker/machineundertaker

`meterstatus`

The meterstatus worker executes the meter-status-changed hook periodically.

See more: juju/worker/meterstatus

`metrics`

See more: juju/worker/metrics

`metricworker`

See more: juju/worker/metricworker

`migrationflag`

See more: juju/worker/migrationflag

`migrationmaster`

See more: juju/worker/migrationmaster

`migrationminion`

See more: juju/worker/migrationminion

`minunitsworker`

See more: juju/worker/minunitsworker

`mocks`

The mocks worker contains common worker mocks.

Run go generate to regenerate the mock interfaces.

See more: juju/worker/mocks

`modelcache`

See more: juju/worker/modelcache

`modelworkermanager`

See more: juju/worker/modelworkermanager

`multiwatcher`

The multiwatcher worker provides watchers that watch the entire model.

It is responsible for creating, feeding, and cleaning up after multiwatchers.

The core worker gets an event stream from an AllWatcherBacking, and manages the multiwatcher Store.

The behaviour of the multiwatchers is very much tied to the Store implementation. The store provides a mechanism to get changes over time.

See more: juju/worker/multiwatcher

`muxhttpserver`

See more: juju/worker/muxhttpserver

`peergrouper`

The peergrouper worker maintains the MongoDB replica set.

See more: juju/worker/peergrouper

`presence`

See more: juju/worker/presence

`provisioner`

The provisioner worker watches LXC and KVM instances, and provisions and decommissions them when needed.

See more: juju/worker/provisioner

`proxyupdater`

See more: juju/worker/proxyupdater

`pruner`

See more: juju/worker/pruner

`pubsub`

See more: juju/worker/pubsub

`querylogger`

See more: juju/worker/querylogger

`reboot`

See more: juju/worker/reboot

`remoterelations`

Package remoterelations defines workers which manage the operation of cross model relations.

Worker: Top level worker. Watches SaaS applications/proxies and creates a worker for each.
remoteApplicationWorker: Manages operations for a consumer or offer proxy. Consumes and publishes relation data and status changes.
remoteRelationsWorker: Runs on the consuming model to manage relations to the offer.
relationUnitsWorker: Runs on the consuming model to receive and publish changes to each relation unit data bag.

The consuming side pushes relation updates from the consumer application to the model containing the offer. It also polls the offered application to record relation changes from the offer into the consuming model.

See more: juju/worker/remoterelations

`retrystrategy`

See more: juju/worker/retrystrategy

`s3caller`

See more: juju/worker/s3caller

`secretbackendrotate`

The secretbackendrotate worker tracks and rotates a secret backend token.

See more: juju/worker/secretbackendrotate

`secretdrainworker`

The secretdrainworker runs on the agent and drains secrets to the new active backend when the model changes secret backends.

See more: juju/worker/secretdrainworker

`secretexpire`

The secretexpire worker tracks and notifies when a secret revision should expire.

See more: juju/worker/secretexpire

`secretrotate`

The secretrotate worker tracks a secret and notifies when it should be rotated.

See more: juju/worker/secretrotate

`simplesignalhandler`

The simplesignalhandler worker responds to OS signals and returns a pre-defined error from this worker when the signal is received.

See more: juju/worker/simplesignalhandler

`singular`

See more: juju/worker/singular

`state`

See more: juju/worker/state

`stateconfigwatcher`

See more: juju/worker/stateconfigwatcher

`stateconverter`

See more: juju/worker/stateconverter

`statushistorypruner`

See more: juju/worker/statushistorypruner

`storageprovisioner`

The storageprovisioner worker manages the provisioning and deprovisioning of storage volumes and filesystems,attaching them to and detaching them from machines.

A storageprovisioner worker is run at each model manager, which manages model-scoped storage such as virtual disk services of the cloud provider. In addition to this, each machine agent runs a machine storageprovisioner worker that manages storage scoped to that machine, such as loop devices, temporary filesystems (tmpfs), and rootfs.

The storageprovisioner worker consists of the following major components:

a set of watchers for provisioning and attachment events
a schedule of pending operations
event-handling code fed by the watcher, that identifies interesting changes (unprovisioned → provisioned, etc.), ensures prerequisites are met (e.g. volume and machine are both provisioned before attachment is attempted), and populates operations into the schedule
operation execution code fed by the schedule, that groups operations to make bulk calls to storage providers; updates status; and reschedules operations upon failure

See more: juju/worker/storageprovisioner

`syslogger`

See more: juju/worker/syslogger

`terminationworker`

The terminationworker stops the agent when it has been signalled to do so.

See more: juju/worker/terminationworker

`toolsversionchecker`

See more: juju/worker/toolsversionchecker

`undertaker`

See more: juju/worker/undertaker

`unitassigner`

See more: juju/worker/unitassigner

`uniter`

The uniter worker implements the capabilities of the unit agent, for example running a charm’s hooks in response to model events. The uniter worker sets up the various components which make that happen and then runs the top level event loop.

See more: juju/worker/uniter

`upgradedatabase`

See more: juju/worker/upgradedatabase

`upgrader`

The upgrader worker schedules upgrades of the agent’s binary, i.e. it upgrades the agent itself.

See more: juju/worker/upgrader

`upgradeseries`

See more: juju/worker/upgradeseries

`upgradesteps`

See more: juju/worker/upgradesteps

Last updated 13 days ago.

Help improve this document in the forum.