Does anyone have a workaround for AWS STANDARD installation issue? (#308)

Does anyone have a workaround for this? I will also try to get AWS Technical Support to help me with this. @stephenwaite @jesdynf
–Ralf

Someone else was having tons of trouble launching it after the upgrade to t3 instances. I need to go through and line-by-line the startup scripts, it looks like. I wanted to see if I could hold off on this until the next release but it doesn’t look like I’ll make it – I’ll try to look at this tomorrow or Wednesday.

1 Like

The switch to Ubuntu 20.04 AMIs and t3 instances for Express Plus/lightsail gave me problems with Python dependency versioning as well as drive mounts (t3 instances map drives as nvme). Haven’t had time to fix the latest issue yet, but it felt like I was getting close. I was troubleshooting by tailing the cloud-setup CFN script on the newly created AWS WebserverInstance resource before it would error and rollback.

The issues I’m working through all have to do with CloudFormation stack instantiation and setup, I don’t anticipate any issues with the actual AMI once it’s up and running, since presumably it has been spun-up in a non-cloud context.

This line likely needs to be changed to pull the Python 3 version of the bootstrap script:

Probably also need to use different version of pip, e.g.: apt-get -y install python3-pip then pip3 install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-py3-latest.tar.gz

Express Plus has resolved the issues with Ubuntu 20 and t3 instances – there’s a /different/ launch problem now I’ve asked the AWS forums for but everything should be straightened out.

I’ll be updating Standard next now that I’ve got the lessons I need.

1 Like

template2.json (40.1 KB)
My issue only occurs if a t3.xxx instead of a t2.xxx is selected for AWS STANDARD. I also opened an AWS Support case on this:
( Case ID 9799062401). The cloudformation stack fails if a t3.xxxx EC2 instance type is selected (instead of the default, which is a t2.small). The workaround is to use t2.xxxx instances only :frowning:

t3 instances map drives as nvme … maybe that could be a factor?

arn:aws:cloudformation:us-west-1:770309817719:stack/openemr-ncalif-2022-03-15-2059h/02af0c00-a4cd-11ec-ae3c-021c5f65240d

Here is the actual error that is generated:
2022-03-15 21:18:48 UTC-0500 openemr-ncalif-2022-03-15-2059h ROLLBACK_IN_PROGRESS The following resource(s) failed to create: [WebserverInstance]. Rollback requested by user.
2022-03-15 21:18:47 UTC-0500 WebserverInstance CREATE_FAILED Received FAILURE signal with UniqueId i-0b4d67ac8a6eea488
2022-03-15 21:17:35 UTC-0500 WebserverInstance CREATE_IN_PROGRESS Resource creation Initiated

The template file that I am using is attached.
–RBL

That’s exactly what it is, yes. Express Plus had two problems to solve, nvme mounts from t3 instances and general Ubuntu 20 chaos (Python is, as usual, terrible in all ways to everyone). Jason did the heavy lifting on both of those, really.

Settling Express Plus was a /lot/ faster than debugging Standard, which is why it got to the front of the line. Tonight I’m going to be verifying that my installation stuff works with the new 6.1.0 release, but after that I’m going to move Standard over to nvme handling (see the recent devops commit if you want to see what changes) and get it on Ubuntu 20 while I’m about it.

2 Likes

OpenEMR 6.1.0 Devops has a running log of work on this issue.

1 Like