As a part of your IoT solution, you have an edge device which runs a Stream Analytics job as a custom module.
Based on the actual data from the previous periods, you updated the job's logic and now you want to update your deployment on the device itself.
As part of the process, you have published the module to your container registry on ACR, sent the deployment manifest to the device.
Everything looked fine, the edge runtime processed the deployment and the device is up and running.
After a short time you notice that the module's behavior is the same as before the update.
What can be the probable reason for that?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer: B.
Option A is incorrect because the device doesn't need to be restarted.
During new deployment the edge runtime is processing the deployment manifest deploying and restarting only the modules affected.
The device itself remains up and running.
Option B is CORRECT because if you publish a new version of a module's container to your container registry using the same version tags as the previous module, the runtime will not download the new version.
So, the new version number must differ from the previous one.
Option C is incorrect because if you publish a new version of a module's container to your container registry using the same version tags as the previous module, the new version won't be downloaded.
Option D is incorrect because there is no such constraint.
Any one of the modules can be deployed/updated independently of the other components on the device.
References:
Based on the given scenario, it seems like the deployment of the updated module to the edge device has been successful, but the module is still behaving as it did before the update. This could be due to various reasons, but the most likely causes are:
Module version number mismatch: When a module is updated and redeployed, it's essential to ensure that the module version number in the deployment manifest matches the version number in the container registry (ACR). If the version numbers are not the same, the edge runtime won't be able to identify the updated module and will continue to run the old module. So, option B (The version number in module.json is the same as its version number in the ACR) could be the probable reason for the issue.
Restart of device required: In some cases, after updating a module, the edge device needs to be restarted for the changes to take effect. This could happen if the module is caching some data, or there are some issues with the edge runtime. So, option A (The device must be restarted so that the changes take effect) could also be a probable reason for the issue.
Updating the Edge runtime required: It's possible that the edge runtime on the device is outdated and doesn't support the updated module. In this case, the updated module won't work correctly until the edge runtime is updated. So, option D (The update of the modules should be executed as part of updating the edge runtime) could also be a probable reason for the issue.
In summary, the probable reason for the updated module not behaving as expected could be a version number mismatch, requiring a restart of the device, or an outdated edge runtime.