specifying the infrastructure Mojaloop will run on

[tdaly61]

Request Summary:

<what platforms and infrastructure should we ensure Mojaloop deploys and runs correctly on >

Request Details:

Per the topic raised at the July 2022 convening, where do we want to ensure Mojaloop works i.e.

• which releases of kubernetes

• which kubernetes distributions (k3s, microk8s , mini-kube, kubespray etc)

• which managed kubernetes engines (AKE, GKE, AKS etc)

• which operating systems

• which operating system releases

• which hardware platforms (x64, arm etc)

• which database(s)

• which database versions

• Deadline:

• Impact (Teams): <this may impact the core teams and those involved in CI/CD for testing >

• Impact (Components):

This request comes from testing enabled by the fast-install of Mojaloop using mini-loop. It became quickly apparent that Mojaloop did not work for a variety of reasons over current versions of kubernetes, on different operating systems etc etc. Moreover there is not an obvious place where we tell users / potential users what infrastructure Mojaloop has been tested on and where they can have great confidence of success.

So this task is NOT an exercise in expanding where Mojaloop deploys and runs , rather it is an exercise in clarifying where we want users and deployers to "have high confidence" that Mojaloop will run , now and in the future especially , in light of the relatively fast moving kubernetes eco-system.

Artifacts:

• TBD: I plan to create a proposal document or set of slides in the next few weeks that will be a starting point to clarifying for users / deployers exactly what is "known to work" i.e. what has been tested and in this proposal I intend to consider how we might modestly expand and automate our testing so as to make this much more explicit than it is today.

Dependencies:

• If Applicable

Accountability:

• Owner:
• Raised By: Tom Daly

Decision(s):

• Approved By:

Details

• Actual decision made as a result of discussion

Follow-up:

• Actions to implement the decisions

[tdaly61]

hi all and especially @elnyry-sam-k @MichaelJBRichards @mdebarros hey right now I am working on DA #91 as we discussed and as tracked in mojaloop/project#2352. As I have gotten deep into doing this task it becomes obvious that if we develop and test for lots of kubernetes versions we are increasing our work and the code complexity but certainly increasing the testing burden or if we just do manual testing then necessarily decreasing our confidence in the outcomes across all the kubernetes versions. I am happy to show why this is the case at the next DA and for the moment I am going to do the work to target v1.21 (old networking API) as well as the current releases because this is where you and I got to @mdebarros. However as v1.21 is already EOL at kubernetes and as it is going EOL on most platforms in the near term then I realise that we need to have this discussion sooner rather than later. Thus I have attempted to divide and conquer the problem in a good agile fashion and rather than an uber suggestion of all the infrastructure components I have put together a small proposal for "what kubernetes versions" we want to ensure Mojaloop runs on as a discussion starter. Please see https://docs.google.com/presentation/d/1A1iDEN0xyvX7pIYIsqTVmeSRE3pCIMk9QksLlMT_LfE/edit?usp=sharing

[tdaly61]

To Summarise on item #1 in our list here is my attempt to document the DA's in-principle decision in preparation for final agreement at today's DA mtg.

General principle: Regarding Item #1 Kubernetes releases
We should test that Mojaloop deploys and runs on the latest current release of kubernetes where the kubernetes release information is defined by the kubernetes releases page at https://kubernetes.io/releases/

Methodology:

• When we publish a new Mojaloop release we will test that it deploys to and runs on the latest kubernetes release (unless of course there are critical known issues with that kubernetes release , then we will test against the most current previous release)
• When this new release of Mojaloop is published it will not be tested against previous/older kubernetes versions

Example:
Releases of Mojaloop from August 2022 Mojaloop will be tested against kubernetes version v1.24 and at end of September 2022 Mojaloop will be tested against kubernetes version v1.25

Implications:
For clarity it is worth mentioning that users will not be forced to adopt new kubernetes releases unless or until they decide to upgrade their Mojaloop release.
Implementing this policy is simply acknowledging that Mojaloop is built on a platform (kubernetes) which is fast moving and releases regularly every 3 months and that there are resource challenges in having a wide test scope.

Considerations:
This policy needs to be widely communicated especially to Mojaloop installed base
On new each release of Mojaloop the kubernetes releases used to test will be documented in the Mojaloop release notes.
There will be further discussion about exactly how to summarise what is tested and not tested in the release notes

[tdaly61]

Revision #1 by Tom Daly
revised the wording of the example to cater for the situation when it is not possible nor prudent to test Mojaloop with the latest kubernetes release.

To Summarise on item #1 in our list here is my attempt to document the DA's in-principle decision in preparation for final agreement at today's DA mtg.

General principle: Regarding Item #1 Kubernetes releases
We should test that Mojaloop deploys and runs on the latest current release of kubernetes where the kubernetes release information is defined by the kubernetes releases page at https://kubernetes.io/releases/

Methodology:

When we publish a new Mojaloop release we will test that it deploys to and runs on the latest kubernetes release (unless of course there are critical known issues with that kubernetes release , then we will test against the most current previous release)
When this new release of Mojaloop is published it will not be tested against previous/older kubernetes versions

Example:
Releases of Mojaloop from August 2022 Mojaloop will be tested against kubernetes version v1.24 until the end of September 2022. From Oct when kubernetes v1.25 is released Mojaloop will be tested against kubernetes version v1.25 unless suitable kubernetes v1.25 products (k3s, microk8s,kubespray etc ) are not readily available at the time and then Mojaloop should be tested with Kubernetes v1.24.

Implications:
For clarity it is worth mentioning that users will not be forced to adopt new kubernetes releases unless or until they decide to upgrade their Mojaloop release.
Implementing this policy is simply acknowledging that Mojaloop is built on a platform (kubernetes) which is fast moving and releases regularly every 3 months and that there are resource challenges in having a wide test scope.

Considerations:
This policy needs to be widely communicated especially to Mojaloop installed base
On new each release of Mojaloop the kubernetes releases used to test will be documented in the Mojaloop release notes.
There will be further discussion about exactly how to summarise what is tested and not tested in the release notes

[tdaly61]

You can see the final wording on this issue at slide #7 at https://docs.google.com/presentation/d/1A1iDEN0xyvX7pIYIsqTVmeSRE3pCIMk9QksLlMT_LfE/edit#slide=id.p7

However what we concluded was

• which releases of Kubernetes <-- done (DA specifying the infrastructure Mojaloop will run on #93)
• Any CNCF recommended k8s distribution which complies with 1. Above.
• Recent Ubuntu LTS
• Hardware (today) x64
• External dependencies : mysql, kafka, mongo, redis , zookeeper

<ALL DONE: during the DA mtg 25th Jan 2003

[mdebarros]

You can see the final wording on this issue at slide #7 at docs.google.com/presentation/d/1A1iDEN0xyvX7pIYIsqTVmeSRE3pCIMk9QksLlMT_LfE/edit#slide=id.p7

However what we concluded was

* which releases of Kubernetes <-- done (DA [specifying  the infrastructure Mojaloop will run on #93](https://github.com/mojaloop/design-authority-project/issues/93))

* Any CNCF recommended k8s distribution which complies with 1. Above.

* Recent Ubuntu LTS

* Hardware (today) x64

* External dependencies : mysql, kafka, mongo, redis , zookeeper

<ALL DONE: during the DA mtg 25th Jan 2003

Hey @tdaly61, I believe some detail is missing from the decision...

See below...

1. which releases of Kubernetes --> Should be "latest k8s version subject to tooling support" (i.e. if the "tooling" does not support the cutting edge of latest K8s version, then we cannot test it until the tooling support is updated to support the latest k8s version)
2. Any CNCF recommended k8s distribution which complies with 1. Above. <-- No issues here.
3. Recent Ubuntu LTS --> Should be "latest Ubuntu LTS version subject to tooling support" (i.e. we cant just deploy any version of an OS, it should match the "support matrix" of the tooling that we are using)
4. Hardware (today) x64 <-- No issues here.
5. External dependencies : mysql, kafka, mongo, redis , zookeeper <-- What is the decision here, exactly?

[elnyry-sam-k]

The clause we agreed on during the DA meetings ".... version subject to tooling support ..." seems to be missing here, which is quite significant

[tdaly61]

Yeah have a look earlier to Revision #1 this is captured for the K8s release. Still this is messy and needs fixing.
We need that single DA decisions page where we post final decisions. I do need to get to that.

[mdebarros]

Yeah have a look earlier to Revision #1 this is captured for the K8s release. Still this is messy and needs fixing. We need that single DA decisions page where we post final decisions. I do need to get to that.

Three points here...

1. What is Revision #1? (Please link it)

2. What is wrong with capturing them as part of an issue like this as that is the DA standard?

3. Also keep in mind that where applicable we should be updating the Mojaloop documentation to reflect the decision...I.e. To me there should be something added to the Standards Documentation(https://github.com/mojaloop/documentation/tree/master/docs/community/standards) to address this going forward. That PR to make that change should also reference this issue so that its tracable.