Cht-core: Figure out how to deploy RapidPro in production

Created on 28 Apr 2020  路  8Comments  路  Source: medic/cht-core

We have a clear interest in integrating with RapidPro and several teams have already built prototypes using TextIt.in. We need to come up with a process for how we would utilize RapidPro in a production environment. This might include things like...

  • Where do we host RapidPro (TextIt.in, self hosted, etc...)
  • How do we control changes to flows
  • Best practices for Flows
  • Monitoring
  • Upgrades
  • Etc...
COVID-19 Technical issue

Most helpful comment

Looks good.

Not saying we need to add these to this doc, but we should also be thinking about:

  1. How we'll approach training/onboarding onto RapidPro from a technical perspective
  2. Statement/guidance on how/when it should be used
  3. RE: Medic SaaS hosting of RapidPro, think about some lessons learned from RDBMS

For #1, I'm just thinking of what we've historically done for KlipFolio and PostgreSQL. Not saying we need to do anything now, but at some point we might want to identify an owner for this to help make sure teammates are aware of it's capabilities, how to implement it, following best practices, etc...

For #2, I'm mostly just afraid of it becoming an interoperability layer that is used to orchestrate API calls in the absence of having a recommended IL. We should be clear as to what it is and what it isn't and / or be prepared to support those other uses.

For #3, having all partners on the same RDBMS makes many things easier, but our permissions/roles setup is not optimal and we should reflect on those challenges when setting up Medic-hosted RapidPro instances (the first paragraph talkings about using the same instance for multiple partners).

All 8 comments

Added to Implementing Partner's backlog as well, since hosting in Europe or in country is required for a partner looking to use RapidPro with the CHT, ideally by June 1st. They can use TextIt while in testing and training phases only, and need to make sure that no patient data is stored in other countries while in production.

Testing our hosted instance and it _looks_ good, but not fully functional.

I was able to create an account, but could not create a new Flow.

image

I also could not import existing flows
image

My thoughts on Medic hosting RapidPro. Feedback and questions welcome!

I haven't tackled "best practices for flows" but we can iterate on that as we get more familiar with configuring flows.

@abbyad Is there anything else I should investigate before closing this off?

Thanks @garethbowen for the detailed investigation!

If we have deployments using RapidPro now, we should provide guidance on when and where to back up the configs so that projects do it in a reliable and consistent way. A couple of lines on that for now would be sufficient.

As for best practices, the only aspect that I would add now is where to keep CHT credentials (eg in globals, never embedded in the flows since they might be accidentally leaked when exporting the flow).

We can continue to add more as we learn, and eventually put parts of this as a guide in the docs site.

Pinging @michaelkohn and @kennsippell in case they have anything else to add.

I have no doubt that we can get a production quality instance up and running with 2-4 weeks of SRE effort

This is a great outcome.

We can continue to add more as we learn, and eventually put parts of this as a guide in the docs site.

I think best practices can be captured comprehensively when we have a complete system using RapidPro. Goma and CIHA are being piloted in the next month or so and I think we'll have a clear picture of what is working. Those projects will definitely have a lot to share on best practices, and change management at that time. Should we split that follow-up into a cht-docs issue?

Looks good.

Not saying we need to add these to this doc, but we should also be thinking about:

  1. How we'll approach training/onboarding onto RapidPro from a technical perspective
  2. Statement/guidance on how/when it should be used
  3. RE: Medic SaaS hosting of RapidPro, think about some lessons learned from RDBMS

For #1, I'm just thinking of what we've historically done for KlipFolio and PostgreSQL. Not saying we need to do anything now, but at some point we might want to identify an owner for this to help make sure teammates are aware of it's capabilities, how to implement it, following best practices, etc...

For #2, I'm mostly just afraid of it becoming an interoperability layer that is used to orchestrate API calls in the absence of having a recommended IL. We should be clear as to what it is and what it isn't and / or be prepared to support those other uses.

For #3, having all partners on the same RDBMS makes many things easier, but our permissions/roles setup is not optimal and we should reflect on those challenges when setting up Medic-hosted RapidPro instances (the first paragraph talkings about using the same instance for multiple partners).

Based on discussion with the Roadmap planning team, we are going to move forward with scheduling with SRE. This is for deploying the MSF-Goma project.

Addl open items:

  • check on RapidPro default gateway to see if any sensitive data is being routed through the US (or outside of Europe AWS hosting).
  • If we use a different gateway, is it still functional with firebase

Unicef and Praekit currently self-host RapidPro and may be able to provide some guidance.

I've created a new issue for the SRE work https://github.com/medic/medic-projects/issues/7478 and one for the documentation: https://github.com/medic/cht-docs/issues/163

Closing as I think this is as far as we need to go on the investigation in 3.10.0. Please reopen if there's anything else I can do.

Was this page helpful?
0 / 5 - 0 ratings