Closed simplesteph closed 3 years ago
Hi @simplesteph, thanks for reporting this. I have identified the bug and we will work on getting a fix implemented. In the meantime here is a workaround for you:
$ eb init --platform "arn:aws:elasticbeanstalk:eu-west-1::platform/PHP 7.4 running on 64bit Amazon Linux 2/3.0.1"
This will update default_platform
in your .elasticbeanstalk/config.yml
file to that specific platform version arn. The bug is in the platform lookup logic around that value, so if you explicitly provide an arn it can skip that portion of the logic.
Hi @halcarleton i have a relatively same issue now when I want to deploy with 'eb deploy'.
The command was working an hour ago and I get this error message now : ERROR: InvalidParameterValueError - Platform 'arn:aws:elasticbeanstalk:eu-west-3::platform/PHP 7.3 running on 64bit Amazon Linux/2.9.4' does not exist.
I tryed the workaround above, both with renaming the versions and keeping your versions, none of the test works, do you have an idea on how to solve it ?
Thanks, Etienne
Hi @crocLeMonde , what you described is not related to this issue. Could you please open a new issue and provide the relevant details as described in the issue template. Thanks
Thanks @halcarleton for your quick answer.
This problem seems to be solved this morning without doing anything on my side, it seems there was a quick change or rollback on AWS side. I may be wrong but I have no other explanation.
The command :
$ eb init --platform "arn:aws:elasticbeanstalk:eu-west-1::platform/PHP 7.4 running on 64bit Amazon Linux 2/3.0.1"
didn't pass. I have the following error:
ERROR: InvalidParameterValueError - Platform 'arn:aws:elasticbeanstalk:eu-west-1::platform/PHP 7.4 running on 64bit Amazon Linux 2/3.0.1' does not exist.
So I manually changed the file .elasticbeanstalk/config.yml
with the arn like this :
default_platform: arn:aws:elasticbeanstalk:eu-west-1::platform/PHP 7.4 running on 64bit Amazon Linux 2/3.0.1
and it's OK for now.
This issue still persists, I am able to resolve it with the workaround suggested by @halcarleton
a483e78392af:HelloWorld $ eb config put prod ERROR: NotFoundError - Elastic Beanstalk can't find a platform version that matches "PHP 7.4 running on 64bit Amazon Linux 2".
a483e78392af:HelloWorld $ eb init --platform "arn:aws:elasticbeanstalk:eu-west-1::platform/PHP 7.4 running on 64bit Amazon Linux 2/3.1.1"
a483e78392af:HelloWorld $ eb config put prod
a483e78392af:HelloWorld $ eb config dev-env --cfg prod
Printing Status:
2020-10-03 09:16:57 INFO Environment update is starting.
2020-10-03 09:17:04 INFO Updating environment dev-env's configuration settings.
2020-10-03 09:17:55 INFO Successfully deployed new configuration to environment.
Experiencing same error using awsebcli 3.19.1 with a different region (us-east-1). As time goes by, the work around requires a different platform version ARN (3.1.2).
To find the correct platform name of for the ARN workaround, look at config.yml for the platform (and adjust your ARN region, too).
@simplesteph Thanks for the report and @halcarleton thank you for the workaround.
@halcarleton This bug reported in May last year is still present. Is there a fix coming..?
I experienced this issue today also. EB CLI 3.19.3 (Python 3.9.1)
ERROR: NotFoundError - Elastic Beanstalk can't find a platform version that matches "PHP 7.3 running on 64bit Amazon Linux"
arn:aws:elasticbeanstalk:ap-southeast-2::platform/PHP 7.3 running on 64bit Amazon Linux/2.9.14
Adding --platform to the eb config put
results in an unrecognized argument error
eb config put staging-sc6 --platform "arn:aws:elasticbeanstalk:ap-southeast-2::platform/PHP 7.3 running on 64bit Amazon Linux/2.9.14"
usage: eb config < |save|get|put|list|delete>
Same exact problem on eb cli 3.19.3 - is a fix forthcoming?
This should be fixed in awsebcli version 3.19.4.
Description
fatal error with the
eb config put
Steps to reproduce
Observed result
Expected result
The command to complete
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Important notes:
In my
prod.cfg.yml
:In the command output:
I think the issue is due to some parsing... it seems the
3.0.1
is missing