Using Greengrass v2. Have a cloud deployment for components including Nucleus, Cli, LocalDebugConsole, LogManager, and SageMakerEdgeManager. Use local deployments for my development work.
I can't upgrade Nucleus without wiping the device entirely and starting from scratch. My attempted upgrade process is:
- Update version requirements in local recipe files to account for the new Nucleus version (in this case, =2.8.1)
- Update version of Nucleus in the cloud deployment to 2.8.1
- Deploy!
I get the magnificent error below upon either deployment, cloud or local, emphasis mine. No available version that matches between =2.8.1 and =2.8.1. This leaves my device and deployment both in a broken state until I wipe and start over.
Can someone give me a step by step process on how to actually upgrade Nucleus and other AWS provided components?
2022-11-04T14:03:22.567Z [ERROR] (pool-2-thread-38) com.aws.greengrass.deployment.DeploymentService: Error occurred while processing deployment. {deploymentId=20c344d2-a99f-4167-8fea-e4dcb8cc28a7, serviceName=DeploymentService, currentState=RUNNING}
java.util.concurrent.ExecutionException: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local component version satisfies the requirement. Component: aws.greengrass.Nucleus version: =2.8.1 =2.8.1
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:126)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:48)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local component version satisfies the requirement. Component: aws.greengrass.Nucleus version: =2.8.1 =2.8.1
at com.aws.greengrass.componentmanager.ComponentManager.getActiveAndSatisfiedComponentMetadata(ComponentManager.java:622)
at com.aws.greengrass.componentmanager.ComponentManager.getActiveAndSatisfiedComponentMetadata(ComponentManager.java:614)
at com.aws.greengrass.componentmanager.DependencyResolver.lambda$resolveDependencies$0(DependencyResolver.java:101)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveComponentDependencies(DependencyResolver.java:216)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveDependencies(DependencyResolver.java:98)
at com.aws.greengrass.deployment.DefaultDeploymentTask.lambda$call$2(DefaultDeploymentTask.java:124)
... 4 more
To update the Nucleus, simply create or revise your cloud deployment and select the latest available version of all components when making the deployment. The most recent versions of components will always be compatible with each other.
Can you please provide the exact local or cloud deployment request which resulted in this error?
When you said "Update version requirements in local recipe files", what does this mean to you? What files did you modify? Your components should not have a dependency on the Nucleus component at all, and if they do, it should be a range, such as
>=2.0.0 <3.0.0.=2.8.1 =2.8.1is not a normal version requirement, do you know where that requirement has come from?Please also provide the output of the following command
sudo /greengrass/v2/bin/greengrass-cli components listCreating the cloud deployment is what created the above error.
I don't know where that
=2.8.1 =2.8.1requirement came from, but it seems to be a conflict between the cloud deployment and the local deployment. It does seem to indicate a bug in Greengrass though.I was able to solve the problem by creating a local deployment to remove all of my development components, running the cloud deployment with the Nucleus upgrade, and then deploying my local components again.
There is definitely a bug in the dependency resolver though. I'd look for it but don't have time.