See first: Juju | Agent
While Juju agents can be counted based on the number of files in the codebase that invoke
dependency.NewEngine, the type of process that they represent depends on the specific
containeragent agent-creating command that they invoke, and the workers that they bring up depend on the specific manifold declaration (files conventionally called
*manifolds.go that invoke
dependency.Manifolds) that is used to configure the dependency engine. Thus, starting from the list of files that invoke a dependency engine, and factoring in these variations, one can distinguish the following agents:
One can think of the list based on invocations of
dependency.NewEngine files as the ‘actual agents’ and of the list of arising from the various splits defined in those files as the ‘logical agents’.
NewMachineAgentCmdand cmd/jujud/agent/machine/manifolds.go or cmd/jujud/agent/model/manifolds.go to define an agent with multiple modes that will run different sets of workers depending on whether the target is a machine (in a machine deployment; with subdistinctions based on whether it is a regular machine or rather a container running on top of a machine; whether the machine carries a controller, model, unit) or a container (specifically, the controller container in a Kubernetes deployment, with subdistinctions for whether it has a model on it as well or not).
NewMachineAgentCmd(indirectly, through the
deployerworker from the cmd/jujud/agent/machine.go agent) and worker/deployer/unit_manifolds.go to define an agent that will run workers for units in a machine deployment.
containerAgentCommandand cmd/containeragent/unit/manifolds.go to define an agent that will run workers for units in a Kubernetes deployment.
NewCaasOperatorAgentand cmd/jujud/agent/caasoperator/manifolds.go to define an agent that will run workers for podspec charms (deprecated).
Last updated a month ago.