AWS Elastic Beanstalk Update – Fixing Incorrect Application Version Error

amazon-web-serviceselastic-beanstalkupgrade

I have 6 Elastic Beanstalk Python 3.7 environments running the same application. Over the course of the weekend, 5 of them have successfully, automatically auto-updated to the latest platform update:

Platform update from 64bit Amazon Linux 2 running Python 3.7 3.3.4 to 64bit Amazon Linux 2 running Python 3.7 3.3.5

Auto update has been running successfully all year but, today, one is steadfastly refusing to upgrade and is just reporting:

FAILED – RollbackSuccessful
Successful abort of the Managed Action.

It appears to deploy the new instance successfully and both the new and old instances get to a point where they say OK
enter image description here

However, instead of the old instance being shut down, after a few minutes, the new instance suddenly reports:

Incorrect application version "app-bd432-13735_111407" (deployment
280). Expected version "app-bd432-13735_111407" (deployment 277).

and the upgrade is rolled back.

So far I have tried:

  1. Just retrying the upgrade
  2. Redeploying the latest version of the app, then retrying the upgrade
  3. Performing Rebuild environment before trying the upgrade

But the result is the same. I can't see any indication in the logs of either instance (old, surviving or new, failing) that offers any help but will be happy to add log info if anyone can suggest a specific log to extract.

Best Answer

It appears that a parameter setting was incorrect. I had been trying to get the AutoUpdate of the platform version to go through, and that was failing silently, but when I tried to manually apply a different version of the platform I got the following message:

Configuration validation exception: Invalid option value: '100' (Namespace:'aws:autoscaling:lanunchconfiguration', OptionName:'RootVolumeIOPS'): '100' is not a valid volume IOPS. Must be between 3000 and 16000.

enter image description here

Updating this parameter allowed the platform update to complete successfully. The parameter had not been changed for several months so I can only assume it had been permitted/ignored in earlier platform versions but more rigorously enforced in 3.3.5.

Related Topic