SearchWhile agents are one part of the system running as processes alongside the Varnish process they are
also a modeling concept. An agent is where a VCL is deployed. An agent is also tagged with one or
more tags. The tags are then used by VCLGroups to tell the system where to deploy a specific set
of VCL files.
An agent can have the following states:
Each agent must have a unique name that is specified during the startup of the agent process. For agents that use different private token the name can be the same as long as different tokens are used for the agents.
Agents becomes Locked when brainz reports wrong unique ID (UID) to them. The brainz UID is created
the first time brainz initializes the database. When agents are started for the first time, brainz
will provide them with this UID. The agents will then only accept deploy/undeploy/reloads from a
brainz instance that uses the same UID.
This functionality is to prevent undeploys if the database becomes reset or destroyed without backups. Starting brainz with a new database, without any data, would otherwise undeploy all VCLs from all agents. This is because the database is empty and brainz will perform deployments based on what is in the database, in this case nothing. So in order to avoid this scenario, the agents that had previous deployments, will become locked.
Locked agents will keep running the previously known VCLs until unlocked.
Before unlocking an agent make sure that the database contains the same settings that should be
deployed to the agents. That means, same tags, deployments, domains, vclgroups and that the agents
have the same tags as before. Once this is added to the database (via API/UI/CLI) the agents UID
file can be removed. The UID file exists in the agents configured base-dir and is called
agent.uid. Remove the file and then restart the agent and the agent will become running again.
Brainz will then update the agent with correct deployments. If the deployments are the same as
before, no undeploys will be made.
However, if the VCLGroup IDs has changed compared to before the database reset, the VCLs will be re-deployed. This will however not remove any cached content and existing sessions will be kept until ended on the previous VCL configuration in Varnish.