GRNsight Lambda port sometimes misses CSS generation

[Onariaginosa]

I was attempting to run GRNsight on my computer (my pre-existing copy from last semester) but it wasn't working on the Onariaginosa branch, the beta branch, or the master branch. GRNsight would load, however, you couldn't load a demo, generate a network, etc. I dropped my schemas in my database and re-loaded the data that didn't work. I once again dropped the data and used a fresh clone of GRNsight and the same issues appeared. I asked @ahmad00m to check and he reported the same issue. I began to suspect that this was a node/npm issue, so I ssh'ed into beta and checked what version was running there, as the production versions were not impacted. I changed my node version to v10.19.0 and my local environment began to work.

This is really strange because I was running node v18 before the break and it isn't working now. Additionally, I tried regressing to version 16 and 14, but they were not compatible with GRNsight either. This may need further investigation, so we can update our initial setup wiki.

[kdahlquist]

@dondi will look into the server to see how far he can push the version of node on the server. Then after that, we will need to stay on the version compatible with the server.

The team will need to learn how to have different versions of node exist on their computers for different projects. @dondi keeps multiple versions and changes the path variable. There are node version managers that can do this, too.

Then we need to document this on the wiki for future reference.

[dondi]

Uptime of our server prior to reboot due to OS upgrade…

[ahmad00m]

I tried changing my path variable for different node versions and it is preferable. Also, I don't mind deleting node and reinstalling a different version of it.

[kdahlquist]

What node version can we use on the server?

The next long-term version of Ubuntu is node 12; the version we are on is node 10. We need to update node on the server. We think @Onariaginosa said she found a minimum version of node 14. So we have a problem.

If we let go of the "long-term" requirement, then we can use node 16. So @dondi tried to upgrade the server and encountered not enough disk space error. He was able to reclaim enough disk space so the server is running, but it's still not enough. So either need to increase the storage of the server or explore a different way to host the server which is not subject to software updates like this. Amazon has a "lambda" tech, which is fundamentally different way to deploy servers. It is not subject to software update problems because Amazon takes care of that part. Amazon takes over the virtual computer and we just worry about our software being compatible with the versions that Amazon supports. We also just need to be concerned with the footprint of our own software.

[dondi]

I have started looking into porting to Lambda. Masao gave me access to the computer science AWS account and I have started looking around

Meanwhile, the node@14 workaround has worked for me, and I was about to write that I think we are OK to start working in this mode, but then I saw @ntran18’s report. Maybe we can compare notes at the meeting

[kdahlquist]

Standardize on node 14.21.2

[Onariaginosa]

Interestingly enough, on node version 14 sequelize was running into errors causing database network calls to never finish, and thus grnsight was not loading. I found an issue pertaining to this documented here. In the issue they said updating to pg@8.0.3 solved this issue for them. I did so and the issue was resolved on my local machine.

[dondi]

Once we have established that this is a necessary update, we will revise and commit package.json accordingly

[dondi]

Lambda update: I have been able to build and deploy GRNsight to a Lambda function on AWS. However, the function does not run correctly yet. It looks like a configuration issue because it cannot find the app starting point for our code…this is under investigation

[dondi]

After some experimentation, the Lambda deployments are now running…somewhat. Memory had to be increased for the Lambda environment plus additional configuration options needed to be set

The latest issue is that most of the Lambda environment is read-only—i.e., files cannot be written out. This runs afoul of our CSS implementation, which does write a file to disk

Current line of investigation now is either to write the CSS file to /tmp (the one location in the Lambda that can be written to) or just generate it in memory when it is requested by the browser

[kdahlquist]

The next step is the Lambda web app needs to talk to the Lambda server. This Lambda is running on node14; will explore taking it to node18. And we may be able to update the node libraries that the server is using, so the server and developers will be in sync.

We would then need a production lambda and beta lambda.

How much will this cost? Lambda's are supposed to be cheaper.

[dondi]

After a few fits and starts, we have… https://2dz4kdk52j37d7xhm6cwi4u4wq0ydwdv.lambda-url.us-east-1.on.aws/#

The grnsight.css and print.css generation is still flaky for me, but when a load successfully retrieves those, I get a working version of GRNsight off Lambda

Next steps would be cleanup and creation of a production version using master. And then…shifting the website to use these servers, and finally when everything looks good, we can potentially decommission grnsight.cs.lmu.edu 😳

[dondi]

Edited title of this issue to reflect what needs to be done more precisely. Comment above this one provides the details

[kdahlquist]

This issue is blocking moving to Lambda. Needs to be open, but lowering priority.