- Newest
- Most votes
- Most comments
Hello,
The deployment is considered as successful when all the components that we check are in their desired state (running/finished). If you are using Run script, Greengrass will not wait for the script, but if the script exits with an error before Greengrass reports back the deployment status - the core will rollback (assuming you have a rollback Config). If you want to perform checks before confirming that the component is healthy, use Startup. With Startup, Greengrass waits until the script returns, and will therefore capture any failure or timeouts. But with startup your code will need to run in background (startup scripts must exit) and use UpdateState
to notify failures after it has started up.
You can find the AWS IoT Device SDK for Python v2 UpdateState
Operation [here] (https://aws.github.io/aws-iot-device-sdk-python-v2/awsiot/greengrasscoreipc.html#awsiot.greengrasscoreipc.client.UpdateStateOperation)
Unfortunately, we do not have any Example code for the implementation of this lifecycle IPC service to update the component state on the core device. And you do not need to add any Authorization policy statement for this feature.
Please note that the PauseComponent
and ResumeComponent
feature will Pause/Resume a component's processes on the core device, if you want to make use of this functionality, only then you should be adding the Authorization policy statement. Addtionally, this operation can't pause containerized processes, such as Docker containers. To pause and resume a Docker container, you can use the "docker pause" and "docker resume" commands.
thank you. what do you mean by a rollback config? Do you mean this inside the deployment json:
"deploymentPolicies": { "failureHandlingPolicy": "ROLLBACK", "componentUpdatePolicy": { "timeoutInSeconds": 60, "action": "NOTIFY_COMPONENTS" } },
Relevant content
- Accepted Answerasked a year ago
- AWS OFFICIALUpdated 24 days ago
- AWS OFFICIALUpdated 4 years ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 3 years ago
I think all the advice you got so far was correct, but maybe not collectively all pulling in the same direction. A question however: how long after installation do you still want a failure to cause a deployment rollback? In my opinion, rollback is the right behaviour if the installation fails or the Docker container fails to start. But if the Docker container fails N seconds/minutes/hours after successfully starting, then the UNHEALTHY state you had in your original question is probably the desired behaviour.
yes, you're right. I just want to trigger Rollback if the installation fails/the docker container or the script fails to start! So what would be the best way to go about this? I am really just deploying a docker container with some dependencies and running a python script therein. I want the deployment to rollback if a new deployment fails to get going. if the script stops at some time t after deployment, I am happy if the device state moves to UNHEALTHY. @Greg_B