All rapyuta.io docs are open source. See something that's wrong or unclear? Submit a pull request.Make a contribution
The lifecycle of a deployment consists of multiple phases. The DEPLOYMENT PHASE indicates the current phase of the deployment in its lifecycle.
The below table lists the phases of deployment as they appear in the lifecycle:
|In progress||accepts request to deploy a package and starts deployment process|
|Provisioning||pulls a docker image and creates a running instance of the image (docker container) for each executable of the component|
|Succeeded||each executable of every component is successfully started|
|Failed to start||error occurred during In progress phase|
|Partially deprovisioned||you deprovisioned a deployment, but there is at least one component that could not be deprovisioned|
|Deployment stopped||you deprovisioned a deployment, and all of its components are stopped|
|Failed To Update||One or more component failed while updating the deployment|
rapyuta.io enables you to monitor the current status of each executable of a component that is deployed. The status of deployment depends on the combined status of all components participating in the deployment.
The following table lists the statuses you may see during the Provisioning deployment phase:
|Pending||docker image is being pulled, or docker container is being created|
|Error||error occurs while pulling a docker image or creating a docker container|
The following table lists the statuses you may see during the Succeeded deployment phase:
|Running||executables of components are running|
|Pending||restarting executable due to runtime error in the application or rapyuta.io software|
|Error||runtime error occurred|
|Unknown||rapyuta.io is unaware of the current status|
If the status of an executable reads Pending or Error, you are provided the cause of the status as Reason.
Unlike deployments running on the cloud, which automatically restart if stopped due to an error, deployments that are running on devices do not automatically restart if exited due to an error or when devices are rebooted.
You can configure the behavior of deployments running on devices by setting their restart policies. There are three kinds of restart policies available for a device deployment:
There are a couple of exceptions while applying the restart policies:
You can modify or override the initial setting of the restart policy while deploying a package. Read deploying a package topic to learn how to do so.
For a deployment running on a device, the variable Restart Count (on the deployment details page) represents the number of times the deployment has restarted due to restarting of deployment components.
After you deploy a package that contains ROS components, you can view the cloud bridge and routed network statuses for each component used in the package. The rapyuta.io platform relies on a sub-component called the cloud bridge for implicitly establishing a communication channel between two or more ROS environments.
cloud bridge instances are automatically generated for the ROS components only.
The following table displays the field description of the network configuration details section.
|Name/ID||Displays a unique name or ID of the cloud bridge component that is generated for a ROS component.|
|Network||Displays the associated routed network for the component.|
|Routing Status||Displays the following cloud bridge statuses of each component for a package.
|Network Status||Displays the following routed network statuses of each component for a package.