Status
The status is a merged property of theactivity status and error status fields, with error states taking precedence over activity states when errors are present.
So, if the error status is none, then the status is simply the activity status. If the error status is not none, then the status is the error status.
Below are examples of status values for different activities and error states.
Target status
The target status is the desired state of a deployment. There are three possible target statuses.
With Staging
If a deployment is staged before being deployed, the diagram below shows the valid transitions between target statuses.
Without Staging
Of course, many deployments skip staging and deploy immediately (such as those deployed from a device’s config editor). The diagram below shows the valid transitions between target statuses for a deployment that is immediately deployed.
One-Time Use
As you can see, the target status can only move forward, never backwards.
Once a deployment’s target status has been set to deployed, it can never be set to staged again. Similarly, once a deployment’s target status has been set to archived, it can never be set to deployed again.
This is intentional—deployments are one-time use. Once a deployment has been deployed, it cannot be redeployed. You must create a new deployment with identical content to roll back.
Activity status
The activity status is the last known state of a deployment. We use the last known state intentionally—poor network connectivity can prevent devices from immediately syncing their activity state with the cloud. In practice, this isn’t too common. However, it’s still a critical point to keep in mind. There are six possible activity states for a deployment.
With Staging
When a deployment is staged before being deployed, its lifecycle has two phases: a review phase and a deployment phase.
During the review phase, a staged deployment may drift if the underlying release changes. A drifted deployment transitions to
drifted and must either be restaged or archived.
Once the deployment is approved, it enters the deployment phase. The deployment is queued for delivery to the device, delivered, and eventually removed and archived.
Without Staging
Deployments which are immediately deployed and skip the staged state have a simpler lifecycle. They simply go through the primary deployment lifecycle from queued to archived, passing through removing when being taken off the device.
One-Time Use
As with the target status, activity states can only progress forward since deployments are one-time.
Error status
The error status is the last known error state of a deployment. Again, we use the last known state intentionally—poor network connectivity can prevent devices from immediately syncing their error state to the cloud. The error status is independent of the activity and target statuses. The error status does not imply any particular activity or target state, and vice versa. The error status is only concerned with errors encountered during deployment. There are three possible error states for a deployment.
Below are the valid transitions between error states.
Deployments start in the none error state. If no errors are encountered, the deployment remains in the none error state for the duration of its existence.
Non-Fatal Errors
If a non-fatal error is encountered, the deployment transitions to the retrying error state. Non-fatal errors include unexpected network drops, sudden power cycles, and similar events.
If the agent recovers the deployment from the error, the deployment transitions back to the none error state once the deployment’s target status is reached.
On the other hand, as long as the agent is unable to recover the deployment, the deployment remains in the retrying error state. The agent continually attempts to reach the deployment’s target status, using exponential backoff to prevent resource throttling.
If the deployment is stuck in the retrying error state, try replacing or archiving the deployment to allow the agent to start fresh.
Fatal Errors
If a fatal error is encountered, the deployment transitions to the failed error state, is removed from the device, and marked as archived.