# Pantavisor 019 Features: Status Goal

In this post, we are going to talk about how to make use of our [status goal](https://docs.pantahub.com/containers/#status-goal) feature included in the [Pantavisor 019 release](https://community.pantavisor.io/t/pantavisor-019-release/).

## Pantavisor Container Status

To understand the concept behind **status goal** we have to first understand how [container status](https://docs.pantahub.com/containers/#status) works in Pantavisor.

After a [Pantavisor-enabled](https://docs.pantahub.com/choose-device/) board is booted up or [updated](https://docs.pantahub.com/updates/), Pantavisor will try to start all [containers](https://docs.pantahub.com/containers/) from the [revision](https://docs.pantahub.com/revisions/). This process will not be immediate, and the container will have to traverse different stages, called **status**. These are the **status** a container can be at:

* **INSTALLED:** the container is installed and ready to go.
* **MOUNTED:** the container volumes are mounted, but not yet started.
* **BLOCKED:** any of the status goals from a container belonging to the previous [group](https://docs.pantahub.com/containers/#groups) are not yet achieved. The concept of **container groups** will be explained on a different post, so it is only necessary to know that this status exists.
* **STARTING:** container is starting.
* **STARTED:** container PID is running.
* **READY:** Pantavisor has received a **signal** from the container.
* **STOPPING:** container is stopping because of an update transition.
* **STOPPED:** container has stopped.

Having this in mind, the **status goal** is the final **status** a container must reach. A [configurable timeout](https://docs.pantahub.com/pantavisor-state-format-v2/#device.json) will make [updates](https://docs.pantahub.com/updates/) [fail](https://docs.pantahub.com/updates/#error) if this objective is not achieved within the defined time. Currently, there are three configurable goals:

* **MOUNTED:** for containers whose volumes we want to be mounted but not started.
* **STARTED:** rest of containers that we want mounted and started, but we only check if its PID is running.
* **READY:** same as STARTED, but a **READY signal** coming from the container namespace is required.

## Setting the Status Goal of a Container

For this example, we are going to try to add a [nginx](https://nginx.org/en/) [container](https://hub.docker.com/_/nginx) to an existing [Pantavisor-enabled device](https://docs.pantahub.com/choose-device/) claimed from my [Pantacor Hub](https://hub.pantacor.com) account:


First step will be to clone our device as usual, in this case, a `Raspberry Pi 4` board with the [Pantavisor 019 image](https://docs.pantahub.com/initial-images/#stable-initial-images) installed:

pvr clone https://pvr.pantahub.com/anibal/home_rpi64_latest
cd home_rpi64_latest

To add the container with a **READY status goal**, we cat explicitly set it in the `pvr app add` command:

pvr app add --from nginx --status-goal READY webserver
pvr add .
pvr commit
pvr post

Let us think what we have done for a bit. We have posted a new revision with an nginx container from [Docker Hub](https://hub.docker.com). Where the developers of this container considerate enough to send a **READY signal** to Pantavisor? Probably not. That is why we are going to get an [ERROR](https://docs.pantahub.com/updates/#error) with this update:


As Pantavisor is expecting a **READY status goal** from the container, the new revision will fail after a [configurable timeout](https://docs.pantahub.com/pantavisor-state-format-v2/#device.json). Now, we are going to try to install another container. This time, a [Container Ready Demo one](https://gitlab.com/pantacor/pv-platforms/container-ready-demo) that we are sure will send the **READY signal**:

rm -r webserver
pvr app add --from registry.gitlab.com/pantacor/pv-platforms/container-ready-demo:arm64v8-main --status-goal READY container-ready-demo
pvr add .
pvr commit
pvr post


This works! But how does the container send the **READY signal** to Pantavisor?

## Sending a Signal from a Container

As we have seen in the previous post, a **READY signal** can be sent from a container to Pantavisor so the **container status** can progress to **READY**. Our [Ready Demo](https://gitlab.com/pantacor/pv-platforms/container-ready-demo) is a mock-up container that sends this **signal** after being started, but the idea is that the container might be able to do internal testing, validation, etc. and then send the **READY signal**.

To send signals, [pvcontrol](https://docs.pantahub.com/local-control/#pvcontrol) can be used:

pvcontrol signal ready