Component life cycle when editing a deployment

Hello,
Components will always run the install step in parallel, there is no way to avoid this. You could move the "apt" calls into the startup phase which can run serially depending on how the component has its dependencies configured. A component will not run the startup phase until all of its dependencies are in the running or finished states.

Performing a deployment will not reinstall components if those components are unmodified. A component will be reinstalled if 1) Greengrass restarts, 2) the component version changes, 3) the component install lifecycle step changes due to a configuration change.

If you don't think that any of these 3 apply, then please provide the Greengrass log file for further debugging.

Cheers,
Michael

Thanks for the quick response.

Does this mean that after restarting the device (and in turn restarting greengrass) it tries to re-install every component?
How about the Bootstrap lifecycle. The documentation https://docs.aws.amazon.com/greengrass/v2/developerguide/component-recipe-reference.html says it is run before the Install lifecycle and only if the component version has changed. Can I use Bootstrap to avoid re-installing all the packages on every reboot?

Thanks.

Hello,
Yes, install will every time after the device reboots or Greengrass restarts; the fact that a component has installed is not persisted.

Bootstrap will only ever run once, however it must be used judiciously as it requires a Nucleus restart everytime you update that component. This means that to make an update, the entire Greengrass system must be stopped, then bootstrapped, then started again. Bootstrap should only be used when you have a particular use case which requires the Nucleus to restart (exit 100 in your bootstrap script) or the device to reboot (exit 101 in your bootstrap script).

Cheers,
Michael

Thanks Michael,

Does this mean that I should avoid having big artifacts in my components? Because after each reboot greengrass tries to download all those artifacts and try to install them.

I wrote a script that checks the version of the deb package that I'm installing and won't try to reinstall if the same version is currently installed. This way I'll avoid the error with the apt lock and I can only change one component in a deployment without an issue.
Now, I'm trying to avoid downloading the artifacts altogether if the version installed on the computer is the same.
Do you have any suggestions?
(Dependency is not going to work out for us, because the components are independent and each deployment could have a combination of all the packages)

Hi,
Install is separate from download. Component artifacts are only downloaded one time during the deployment. What I've been talking about is the "install" lifecycle step which you define in the component recipe. Additionally, there is a "skipIf" keyword which you can use to skip running a lifecycle stage if a file or command exists already. See https://docs.aws.amazon.com/greengrass/v2/developerguide/component-recipe-reference.html and search for "skipIf".

So hopefully that addresses your concern.

When you say that you want to avoid downloading the artifacts, what artifacts are you referring to? Artifacts downloaded as part of your component's lifecycle scripts, or are these artifacts in the recipe which Greengrass would download? If they are downloaded by Greengrass, then they are only ever downloaded once for each version of the component.
If you have common artifacts, then putting them all into a single component and having your other components reference that one is a typical use case. If you say that you cannot do that, then I'm not sure what you are looking to do, please clarify your requirements.

Cheers,
Michael

Sorry about that. Let me clarify.

1- Do the artifacts defined in the recipe (in the Artifacts section) download only once for each version of the component? Or only once for each deployment?
2- If I change a component in a deployment and deploy again. Does greengrass download all other components too (does it download the artifacts for them? we know that it does call the install cycle, but does it also download the artifact?)
3- You mentioned "Artifacts downloaded as part of your component's lifecycle scripts, or are these artifacts in the recipe" which suggests there could be two types of artifacts. I was talking about the artifacts that one would add in the Artifacts section of the recipe, but is it even possible to download artifacts in a lifecycle script? For example can I explicitly download an artifact in the Run cycle, but not the Install cycle?

I don't know if it is clear. Thanks for the help by the way. This is very helpful.

1. Once per component version. If the artifact exists already on disk and the checksum matches the checksum which is in the recipe (this is automatically added by Greengrass cloud service) it will not be downloaded.
2. Same answer as above. If you are deploying any number of components then only the files that have changed or do not exist already will be downloaded.
3. Greengrass doesn't know or care what you do in your lifecycle scripts, so you can certainly use any mechanism of your choosing to download files from anywhere. Just as some random example: "wget <my url> && unzip file && python file"

1,2- I have seen greengrass downloading the same package over and over again while it hasn't changed in a while (when I change another component and deploy again). I will keep an eye on the logs to actually debug it if it happens again.
3- Oh. Yes. I thought there is a special mechanism (just like the Artifact section) that you could define more artifacts for a specific cycle. Then I can download my packages from s3 conditionally.

Thank you for your help.

1,2 - You may see this behavior if your deployment fails and rollsback. After the rollback we will cleanup any unused artifacts which would include the artifacts that we just downloaded for the deployment which was then rolledback.

That might be it. But I have set "Failure handling policy" to "Don't roll back" since months ago. Would a failure cause a clean-up even if the rollback is disabled?

If it did not roll back, then it would still be "running" the broken version of a component and since that version is active it would not be cleaned.

Cheers,
Michael