ARXIVNG-3018: Submission UI readme updates

[bmaltzan]

I found the submission-ui readme very helpful, and the docker-compose config has made it easy to get all those pieces up and running.

Along the way, there were a couple of things I got caught on:

• I left a local version of mysql running, which collided with the docker mysql ports, and wasn’t obvious from the logs.
• I didn’t read past the full-compiler details, to find the JWT instructions, so was redirected to production login initially.
• I had docker crash twice when running the full compiler version, and increased the ram to 4g. I’m not sure its needed or related to other issues.

I was able to ‘aws ecr list…’, but not 'docker pull …dkr.ecr…’. The fix was: ‘aws ecr get-login.’ I’m guessing the first ran by reading my ~/.aws/config. I assume there isn’t anything exposed here.

I have a few changes that may be helpful for the next person getting started. I tried things that seem like obvious tangents now, but a few days ago were unknown possibilities. I suggest reorganizing the readme and adding two milestones. First get the mock-compiler running, then get the full compiler running. I think this will narrow down the options. There’s less background initially, but I like that the instructions fit on a single screen. How does this sound?

[claassistantio]

All committers have signed the CLA.

[bmaltzan]

The improvements and general reorganization look great to me. I'm wondering whether the mock docker-compose configuration should eventually become the default with docker-compose-with-compile becoming an optional configuration.

I believe we've all run into docker memory issues and ultimately increased the docker memory setting to 4G. Insufficient memory causes some very flakey behavior in the Submission UI application. The Submission UI is large and complicated with it running several microservices so I'm wondering if 4G is really a 'must' for the README file.

Any thoughts on detecting/avoiding the MySQL port conflict. You mention that it was difficult to detect so any advice here might save someone else from unnecessary pain in the future.

Changing what docker-compose means could make things simpler for the more common case run by developers. I wonder if that would cause confusion with what should run in production?

I added the 4G memory setting

The MySQL conflict didn't occur to me initially. I went through the confluence getting-started guide, installed it, and then lost track of it. When I started this project in docker, there's a lot running that I'm just trusting to run. In the confluence getting started page, I moved the MySQL install instructions, to a lower priority list. Maybe that will help. Here, I also added a section for common issues with instructions for checking for a duplicate MySQL.