Closed tdaly61 closed 1 month ago
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 https://github.com/mojaloop/project/issues/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
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:
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
To Summarise on item https://github.com/mojaloop/design-authority-project/issues/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 https://github.com/mojaloop/design-authority-project/issues/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
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
<ALL DONE: during the DA mtg 25th Jan 2003
You can see the final wording on this issue at slide
#7
at docs.google.com/presentation/d/1A1iDEN0xyvX7pIYIsqTVmeSRE3pCIMk9QksLlMT_LfE/edit#slide=id.p7However 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...
The clause we agreed on during the DA meetings ".... version subject to tooling support ..." seems to be missing here, which is quite significant
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.
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...
What is Revision #1
? (Please link it)
What is wrong with capturing them as part of an issue like this as that is the DA standard?
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.
All items in the original request are covered in new release note format except:
@elnyry-sam-k : We should probably state what OS/platform we have tested on rather than what we "support". If we attempt to "support" multiple OS/Platforms the matrix for testing will grow rapidly making pre-release testing unmanageable and very costly.
Official DA decision made with following majority of DA voting members present: @bushjames , @elnyry-sam-k , @PaulGregoryBaker , @vijayg10 , @JulieG19 :
Current release notes give sufficient information in support of the above, example: https://github.com/mojaloop/helm/releases/tag/v16.0.0
Issue to be closed as completed.
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:
Dependencies:
Accountability:
Decision(s):