Next steps for the harmony project

[felipemontoya]

In our last WG meeting we touched the issue of what the goals for this project will be in the next 6 Months.
We are talking from now until the next open edX conference were I hope we will have the chance to meet in person.

In this issue I would like to invite you all to leave the ideas or the pain points you are facing that you think this project could help solve in the near future.

@bradenmacdonald @gabor-boros @jfavellar90 @cmltaWt0 @jmbowman @MoisesGSalas @CodeWithEmad

During the meeting we floated some ideas that are gathered in the meeting notes.

[jfavellar90]

There are a couple of points I would like to mention:

• This is a suggestion to make this project more manageable. Right now we are adding a lot of dependencies to the Harmony chart, which could become problematic at some point. Imagine I want to enable all the sub-charts and install the harmony chart; if it fails, it could be hard to debug the reason for the failure. From the gitops perspective, a single helm-chart controls a lot of resources, making it difficult to install and manage.
  What I propose is to break the current Helm chart into smaller charts that contain the dependencies for specific functionality. For instance, we could have a chart that controls the ingress functionality, including in its dependencies just ingress-nginx and cert-manager. Another one for monitoring, including kube-prometheus-stack and kube-dashboard in its dependencies. I find this approach more maintainable by enabling the separation of concerns.
• We should start working more on the Harmony Tutor plugin. From our experience operating OpenedX in Kubernetes, we could add features that help operate large instances. A few ideas:
  • Pod disruption budget implementation
  • Pods lifecycle (graceful termination of services, readiness and liveness probes, among others)
  • Better ingress configuration
  • Fine tuning of services (uwsgi, celery, etc, related to this issue)
    Additionally, we could define a versioning mechanism for this plugin and also a maintenance policy to make sure we provide support for the latest Tutor version.
• On the monitoring side of things, work on proposing a simple dashboard to monitor an OpenedX installation. This can help operators to spot problems, specially on large instances