Demo farm and up for grabs demos are back!

Demos are back up. I didn’t do anything (the connections timeout after awhile) and think that will be able to prevent this in the future by increasing the max_connections settings.
-brady

thanks @brady.miller , are you changing this setting https://dev.mysql.com/doc/refman/5.7/en/too-many-connections.html

hi @stephenwaite ,

yep, changed that setting from 150 to 350 and monitoring it over time to see how it goes. Can see here for more details:

-brady

btw @visolveemr ,

Working on the wordpress emailing issue here:


(I think i just need to get it sorted out on aws end)

-brady

Hi @visolveemr ,

Registration emails from wordpress are now working on the demos. They are now being sent via AWS SES email service, so should be reliable. Let me know if still not working for you.

-brady

Hello @brady.miller ,
We have analyzed on the Demo and following are results.

  • Main Demo:
    Mail is working.

  • Alternate Demo:
    Mail is working.

  • Alternate Demo - php7.1:
    Mail is working but login page is having 500 internal server error.

  • Alternate Demo (Alpine 3.5):
    Mail is not working.

  • Alternate Demo (Alpine 3.6 - uses php 7.1):
    Mail is not working.

In a Development Demo(192.168.1.134) while logging out of the Wordpress There is a failure notice(Wordpress Failure Notice) as attached in the image. Is this a expected one?

Thanks,
ViSolve

Dang,

Nothing gets by your group :smile:

Still working on getting Alpine to play nicely with Amazon SES email service (just need to work out the stunnel/postfix config for Alpine and then that should work also). Regarding php 7.1, we really need to start testing those 7.1 demos (especially OpenEMR parts) and fix those bugs since 7.1 will soon be de facto php standard, and the goal is for OpenEMR 5.0.1 (likely to be releases in 6-8 weeks) to be completely 7.1 compatible.

thanks for the testing and reporting and I’ll let you know when the Alpine is working,
-brady

Hi,

Demos are down secondary to “degradation” of the aws instance per email I just got(should be able to rebuild another instance in the very near future):

Dear Amazon EC2 Customer,

We have important news about your account (AWS Account ID: ****). EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: ***) in the us-west-2 region. Due to this degradation, your instance could already be unreachable. After 2017-10-09 13:00 UTC your instance, which has an EBS volume as the root device, will be stopped.

Demos are back up. Lucked out; just stop/started the aws ec2 instance and it still worked. Gonna do a backup so don’t need to do a full rebuild if this happens again. I hope this is not a common occurrence with aws.
-brady

hi,

Just an update on the ongoing demo farm revolution. I was under the impression that the current aws t2.medium instance was going to limit us to 10 demos(note each demo uses a docker container and the t2.medium instance has just 4GB of memory). However, @robert.down suggested that to decrease the overhead, it would make sense to serve multiple demos from each docker container. So, have added the ability to have 10 subdemos per docker and did this to 1 docker to see how things work, which seems to be working well. This basically means we are serving 20 demos now and could likely serve many more; of course this is because the traffic is almost all to one demo (the official demo linked from main website), and if they all got heavy use they may run into some issues :slight_smile:

I made all the new demos Up For Grabs demos, which we now have 12 of :slight_smile:
http://www.open-emr.org/wiki/index.php/Development_Demo#UP_FOR_GRABS_Development_Demos

This mechanism will also prove helpful in the plan to support education(since could basically make a stream of demos that deal with a set of instructions sets with very minimal overhead):

@visolveemr , btw, still working on the alpine email issue.

-brady

1 Like

btw, if anybody is curious, here is the “brain” of the demos where the config for each demo is(where the code comes from and some configuration options):

Note each row is a demo.
If the 1st column is a number(ie. four), then is a docker (that is run on the aws instance).
For the 1st column items like four_a etc. these are the subdemos(that would be in four docker for example).
If the 1st column is an ip address, then is for the old demos (these are still running in my closet).

-brady

Hi,

More news on the demo farm revolution. We now have a 5.0.0 demo with actual demo data:
http://www.open-emr.org/wiki/index.php/OpenEMR_Demo

That demo commonly gets thrashed and broken (appears that get 20+ users per day using it), and commonly has some rather crazy ui settings. So added an alternate demo on the above demo page (was easy with current demo farm mechanism) which can see as links below main demo links with “Alternate Demo Link”. I guess the question here is 1 alternate enough; could easily add another alternate demo, but I think that may confuse new users that are using the demo.

btw, coming soon is a development demo (builds daily from most recent codebase) with demo data in it (this won’t be too tough since will basically just take the 5.0.0 demo data and run the sql-upgrade.php script on it in real time, so this demo will also be nice daily test for sql-upgrade.php).

-brady

Hi,

More news on the demo farm revolution.

The development demos (daily builds from most recent development codebase; ie. master branch) now include demos with demo data in them:
http://www.open-emr.org/wiki/index.php/Development_Demo#Daily_Build_Development_Demos

It’s pretty cool and basically does some magic using the sql upgrade script, so it should keep working far into the future(and are also nice daily tests for the sql upgrade script).

btw, we now offer 25 separate OpenEMR demos from the aws t2.medium instance via the demo farm :smile:
(I am still amazed how aws can basically reset them all at the same time within 15 minutes, which involves grabbing more than 3 GB of data from github repos along with very large amount of simultaneous cpu intensive mysql imports)

-brady

Doubtful they have to actually download each time. Only changed files and those most likely update when file change happens.

I agree with @sjpadgett, probably don’t need to do pull from github for all the instances. It’d be more efficient to pull it once and let it live on the server and have the demos pull from the local repo and have that just doing a nightly pull.

@sjpadgett and @robert.down ,
Do plan to hopefully attack this issue down the road to improve efficiency (will basically keep a “cache” of repositories that have been used and update that “cache” git repo rather than completely download it, if it exists; being able to use volumes on dockers makes these kinds of things much easier to support). This will involve substantial work for not a huge gain (aws does not charge for this huge amount of incoming data, so it basically just speeds up the time it takes to reset the demos), so it’s a future todo.
-brady

Doesn’t the docker instant reside in the cloud? I maintain my own cloud but I use a shared folder that app lives and changes to client source is sync’ed to server. Don’t know docker but a biggy of the cloud is for sharing resources. Just my thoughts, I understand time/effort.

Just a cool factoid. The demo farm is now running 38 OpenEMR demos :smile:

1 Like

Just added a Alpine Edge docker (this is basically development code for Alpine and is using PHP 7.2) on the demo farm to allow testing of most recent codebase on Alpine Edge:
https://www.open-emr.org/wiki/index.php/Development_Demo#Alternate_Demo_.28Alpine_Edge_-_uses_php_7.2.29

The demo farm is now running 40 OpenEMR demos without blowing up yet :smile:

With the recently added 5.0.1 demos at https://www.open-emr.org/demo/ , the demo farm is now running 43 OpenEMR demos :slight_smile:

1 Like