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...
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.

I also could not import existing flows

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:
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:
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.
Most helpful comment
Looks good.
Not saying we need to add these to this doc, but we should also be thinking about:
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).