Strategy for shipping new monarch-ui

[DoctorBud]

@nathandunn @tomc @kshefchek and @DoctorBud had an opportunity to meet in Eugene yesterday and we came up with a plan that would allow us to move the monarch-ui to production at https://monarchinitiative.org, while satisfying constraints like

• Continue to support https://monarchinitiative.org/<id>.json for legacy API users
• Continue to support https://monarchinitiative.org/<type>/<id>.json for legacy API users
• Continue to support https://monarchinitiative.org/score for legacy API users
• Continue to support https://monarchinitiative.org/??owlsim?? for legacy API users (@kshefchek what is the other legacy API endpoint folks might be using?)
• Allow for legacy functionality to be visible (for comparison and testing) via https://legacy.monarchinitiative.org

I've refined the plan we discussed so that it is more symmetrical and beta vs production distinctions are clearer. In addition, this strategy doesn't require any complex DNS-swap like I was proposing yesterday.

Phase 1a - Create legacy.monarchinitiative.org

• Will require @Kennric to tweak HAProxy to direct traffic for legacy.m.org to the current production VM containing m.org.
• Might require GoDaddy to declare the subdomain legacy.m.org (is this true @kshefchek @Kennric?)

Phase 1b - Create legacybeta.monarchinitiative.org

• Will require @Kennric to tweak HAProxy to direct traffic for legacybeta.m.org to the current beta VM containing beta.m.org.
• Might require GoDaddy to declare the subdomain legacybeta.m.org (is this true @kshefchek @Kennric?)

Phase 1c - Create preview.monarchinitiative.org

• Will require @Kennric to tweak HAProxy to direct traffic for preview.m.org to the current production VM containing m.org.
• Might require GoDaddy to declare the subdomain preview.m.org (is this true @kshefchek @Kennric?)
• This preview.m.org domain will only be used until the final 'nginx swap' on production. It will allow us to verify that monarch-ui can be deployed on the production VM and that legacy API routing on the production VM is working.
• Once we do the final swap on production, we can delete this subdomain.

Phase 2 - Update monarch-app-beta VM with latest legacy monarch-app

• This VM has previously served up monarch-app, and everything is installed.
• However, the monarch-app service has been disabled since we began serving monarch-ui from here.
• So this step is really about making sure that the monarch-app code on beta is the same as that on production. Might be doable with Jenkins

Phase 3 - Verify that legacy.m.org and legacybeta.m.org work

• URLs like https://legacy.monarchinitiative.org should lead to the legacy monarch-app on production
• URLs like https://legacybeta.monarchinitiative.org should lead to the legacy monarch-app on beta
• Assuming HAProxy is configured right, then the nginx conf on beta/prod will need to be adjusted so that those VMs can serve both monarch-app and monarch-ui.
• Remember that legacy.m.org is the same monarch-app-prod VM as m.org.
• Remember that legacybeta.m.org is the same monarch-app-beta VM as beta.m.org.

Phase 4 - On beta, use nginx to route legacy paths to legacybeta.m.org

• We'll try this out on beta first, so that legacy production is not disrupted until we know things work.
• We'll adjust nginx so that a request asking for https://beta.monarchinitiative.org/MONDO:0007947.json, a legacy API, will NOT end up running the new monarch-ui, but will instead be transparently routed to https://legacybeta.monarchinitiative.org/MONDO:0007947.json
• Do this for the known legacy paths: /MONDO:0007947.json, /disease/MONDO:0007947.json, /score, and ??owlsim??.

Phase 5 - Install monarch-ui on production as preview.m.org

• Duplicate the monarch-ui-beta Jenkins task and call it monarch-ui
• Create any necessary directories on production to hold monarch-ui
• Deploy monarch-ui to production
• Adjust production nginx to route preview.m.org to monarch-ui

Take a breath

• At this point, legacy production has not been affected.
• https://beta.m.org will display the new monarch-ui
• https://legacybeta.m.org will display the legacy monarch-app
• https://m.org will still result in displaying legacy UI and will be identical in behavior to https://legacy.m.org
• https://preview.m.org will result in displaying the new monarch-ui
• Legacy API routes like https://preview.m.org/MONDO:0007947.json will be satisfied by nginx routing to legacy.m.org.

Phase 5 - Ribbon-cutting Ceremony ... 'Make it So!'

• Adjust production nginx config so that m.org points to monarch-ui
• Profit!
• If something goes horribly wrong, then just undo the edit(s) to nginx so that m.org points to monarch-app.

[nathandunn]

It looks like a nice weekend project

[DoctorBud]

I believe we have now completed Phase 4 of #91

• https://beta.monarchinitiative.org points to new UI

• https://beta.monarchinitiative.org/gene/NCBIGene:8854.json proxies to legacy app running on beta (returns JSON)

• https://beta.monarchinitiative.org/score, https://beta.monarchinitiative.org/simsearch, https://beta.monarchinitiative.org/owlsim also proxy to legacy app

• https://preview.monarchinitiative.org runs new UI on production

• https://preview.monarchinitiative.org/gene/NCBIGene:8854.json proxies to legacy app running on production (returns JSON)

• https://preview.monarchinitiative.org/score, https://preview.monarchinitiative.org/simsearch, https://preview.monarchinitiative.org/owlsim also proxy to legacy app running on production.

• https://legacybeta.monarchinitiative.org/ points to legacy app running on beta

• https://legacy.monarchinitiative.org points to legacy app running on production.

[pnrobinson]

@cmungall @monicacecilia @mellybelly @iimpulse @kshefchek
It seems insane to me that we want to support a legacy site when it has taken so long to get the new site finished. Given that the new website will support afaik all of the previous queries but in a more correct way, why would we even want to allow users to see a less correct view of Monarch data? Given that we are so strapped for resources and time as it is, I would propose that we go cold turkey and put all of our efforts into the new site.

[kshefchek]

This is to allow us to maintain a small number of rest endpoints supported by our legacy api - simsearch, compare, score, {id}.json. We have not communicated with our users in any way that we will be removing support, so that's the first step. I agree we should strip away the front end to avoid confusion, and make it purely a rest API with those functions.

[nathandunn]

My sense is the sooner you do that the better. just suggest migrating to biolink and provide a timetable of one to two weeks and to contact you if a problem. Nathan

…

On Jul 10, 2019, at 9:53 AM, Kent Shefchek ***@***.***> wrote: This is to allow us to maintain a small number of rest endpoints supported by our legacy api - simsearch, compare, score, {id}.json. We have not communicated with our users in any way that we will be removing support, so that's the first step. I agree we should strip away the front end to avoid confusion, and make it purely a rest API with those functions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kshefchek]

I think if it purely switching URLs to biolink it would be good and well, but the endpoints have different arguments and json responses, I think some calls like {id}.json now require going to two different endpoints for the same data - I just see it potentially taking users longer to change their code. And it takes little resourcing from us to run a tiny nodejs app.

@monicacecilia do we have anyone tasked with emailing our users?

[monicacecilia]

Hi @kshefchek. You and I chatted about communicating with our users a little while ago; see also exchanged messages in this ticket (https://github.com/monarch-initiative/operations/issues/111). First, we need a list of users and contact information.