Versioning PI-12 Objectives

Development
#1

I want to open the discussion on the PI12 Objectives for the versioning workstream.

Here’s what we mentioned in our presentation:

  • Implement auto-releasing for our code pipelines

    • Improve release notes
    • Consolidate CI/CD Config across all repos

  • ml-operator v1.1

    • Apply image patches upon confirmation
    • Nice UI for hub operators
    • Automatically apply upgrades during an upgrade window

  • Data migrations + Upgrades

    • Revisit our zero downtime deployment POC

We also need a single sentence that summarizes our goals in a SMART fashion.

2 Likes
#2

This looks good @lewisdaly, may be we can call the third one as a stretch goal and add measuring criteria to each (as you indicated)…

#3

hey @lewisdaly. how does the below look:

  1. Implement auto-releases for all core repositories in CI/CD [Measurability criteria: Improved release notes, Consolidate CI/CD Config across relevant repos]
  2. Enhance ml-operator (v1.1) to apply image patching upon confirmation by Hub Operators with configurability options for automation [using a user interface - stretch goal] [Measurability criteria: Apply image patches upon confirmation]
  3. Streamline Data migrations + Upgrades based on inputs from current implementers and leveraging the zero-down-time PoC {stretch goal]
#4

Thanks for following this up. Yeah I’m happy with that. I’ve started adding ml-operator specific tickets to the board.

1 Like
#5

How about further enhancing the ml-operator to actually handle the installation of Mojaloop and its pre-requisites?

It was discussed that we want a one-button installation for Mojaloop. I believe the ml-operator is the perfect conduit to handle this.

I.e. It could have the functionality to deploy the pre-requisites, and also deploy Mojaloop. This would only be applicable once we remove the external dependencies from the mojaloop helm chart.

#6

This is a great idea Miguel.

One of the biggest challenges here will be the relationship between the operator and helm - from the oprerators I’ve looked into in the past, they have different ways to tackle this. Here’s a few ideas:

  1. The Mojaloop Helm chart installs and configures the ml-operator, the operator installs the rest of Mojaloop
  2. Remove the need for helm completely - just install the operator, and then the operator installs the rest of Mojaloop with plain old Kubernetes
  3. Install the operator (with or without helm) and then the operator uses helm to install Mojaloop

Each of these approaches will have benefits and drawbacks, especially when it comes time to version releases etc.

Perhaps we should start with looking at the ml-operator as a “flavour” of installation, and once we see how that might work, we will be better equipped to answer these questions.

1 Like