You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mojaloop foundation should adopt and apply the well known industry design principle of DRY throughout the code base and all artifacts supplied as part of a Mojaloop release.
DRY, which stands for 'don't repeat yourself,' is a principle of software development that aims at reducing the repetition of patterns and code duplication in favor of abstractions and avoiding redundancy. This helps to make software easier to understand, simpler and more cost effective to maintain and secure.
Request Details:
Deadline: end of April would seem feasible and useful
Impact (Teams): core development team could benefit from adoption of this as well as Mojaloop users/community
Impact (Components): Pretty much all of our repos would be affected by this change over time as they would be nudged in the direction of simplicity
So far I am not dealing with the node code within the containers , so my key example is related to the > 41K lines of helm often repeated configuration settings that Miguel and I have been debating. Please see below for details.
Artifacts:
See below for the line counts
Dependencies:
If Applicable
Accountability:
Owner: Tom Daly
Raised By: Tom Daly
Decision(s):
Approved By:
Details
It is important to understand that Helm charts can be nested
So for instance the chart-admin chart is nested in the account-lookup-service chart which is nested in the mojaloop chart with the upper value setting (if set) overriding the lower value (see diag)
In this request I am NOT asking we be prescriptive on how to implement DRY, that detail can and should in the end stay at the workstream level , that said a good understanding of the issue and a recommendation by the DA on this particular case may prove useful now and as an example for the future.
To give an idea of impact : Adopting and applying a DRY approach would very likely reduce the values files by 50% or more (as some values as you can see are replicated many times and there are errors in that replication). It would also mean we can more faithfully comply with the outcome of DA *97 which is to test (well) what we release.
Actual decision made as a result of discussion
Follow-up:
Actions to implement the decisions
The text was updated successfully, but these errors were encountered:
Request Summary:
Mojaloop foundation should adopt and apply the well known industry design principle of DRY throughout the code base and all artifacts supplied as part of a Mojaloop release.
DRY, which stands for 'don't repeat yourself,' is a principle of software development that aims at reducing the repetition of patterns and code duplication in favor of abstractions and avoiding redundancy. This helps to make software easier to understand, simpler and more cost effective to maintain and secure.
Request Details:
So far I am not dealing with the node code within the containers , so my key example is related to the > 41K lines of helm often repeated configuration settings that Miguel and I have been debating. Please see below for details.
Artifacts:
Dependencies:
Accountability:
Decision(s):
Details
It is important to understand that Helm charts can be nested
So for instance the chart-admin chart is nested in the account-lookup-service chart which is nested in the mojaloop chart with the upper value setting (if set) overriding the lower value (see diag)
Just to give the data on the example: from Mojaloop v14.1.0
ubuntu@miniloop-vm:~/helm$ find . -name values.yaml | xargs wc -l
109 ./finance-portal-settlement-management/values.yaml
143 ./simulator/values.yaml
614 ./sdk-scheme-adapter/chart-service/values.yaml
1418 ./sdk-scheme-adapter/values.yaml
3125 ./mojaloop-bulk/values.yaml
183 ./transaction-requests-service/values.yaml
32 ./kube-system/ntpd/values.yaml
154 ./emailnotifier/values.yaml
558 ./example-mojaloop-backend/values.yaml
86 ./ml-testing-toolkit/chart-frontend/values.yaml
70 ./ml-testing-toolkit/chart-connection-manager-backend/values.yaml
423 ./ml-testing-toolkit/chart-keycloak/values.yaml
34 ./ml-testing-toolkit/chart-connection-manager-frontend/values.yaml
157 ./ml-testing-toolkit/chart-backend/values.yaml
298 ./ml-testing-toolkit/values.yaml
158 ./bulk-api-adapter/chart-service/values.yaml
176 ./bulk-api-adapter/chart-handler-notification/values.yaml
304 ./bulk-api-adapter/values.yaml
128 ./thirdparty/chart-tp-api-svc/values.yaml
157 ./thirdparty/chart-consent-oracle/values.yaml
159 ./thirdparty/chart-auth-svc/values.yaml
1654 ./thirdparty/values.yaml
208 ./centralkms/values.yaml
321 ./forensicloggingsidecar/values.yaml
801 ./monitoring/efk/values.yaml
1993 ./monitoring/promfana/values.yaml
200 ./ml-api-adapter/chart-service/values.yaml
225 ./ml-api-adapter/chart-handler-notification/values.yaml
678 ./ml-api-adapter/values.yaml
658 ./mojaloop-simulator/values.yaml
2515 ./centraleventprocessor/values.yaml
213 ./centralenduserregistry/values.yaml
225 ./quoting-service/values.yaml
231 ./bulk-centralledger/chart-handler-bulk-transfer-processing/values.yaml
218 ./bulk-centralledger/chart-handler-bulk-transfer-fulfil/values.yaml
218 ./bulk-centralledger/chart-handler-bulk-transfer-get/values.yaml
221 ./bulk-centralledger/chart-handler-bulk-transfer-prepare/values.yaml
840 ./bulk-centralledger/values.yaml
387 ./centralsettlement/chart-service/values.yaml
1387 ./centralsettlement/values.yaml
4015 ./central/values.yaml
108 ./mojaloop-ttk-simulators/chart-sim3/values.yaml
117 ./mojaloop-ttk-simulators/chart-sim1/values.yaml
249 ./mojaloop-ttk-simulators/values.yaml
108 ./mojaloop-ttk-simulators/chart-sim2/values.yaml
180 ./finance-portal/values.yaml
112 ./ml-operator/values.yaml
257 ./account-lookup-service/chart-admin/values.yaml
253 ./account-lookup-service/chart-service/values.yaml
786 ./account-lookup-service/values.yaml
304 ./als-oracle-pathfinder/values.yaml
100 ./ml-testing-toolkit-cli/values.yaml
8562 ./mojaloop/values.yaml
257 ./centralledger/chart-handler-transfer-fulfil/values.yaml
262 ./centralledger/chart-handler-timeout/values.yaml
257 ./centralledger/chart-handler-admin-transfer/values.yaml
257 ./centralledger/chart-handler-transfer-position/values.yaml
252 ./centralledger/chart-service/values.yaml
257 ./centralledger/chart-handler-transfer-get/values.yaml
260 ./centralledger/chart-handler-transfer-prepare/values.yaml
2109 ./centralledger/values.yaml
520 ./eventstreamprocessor/values.yaml
41261 total
In this request I am NOT asking we be prescriptive on how to implement DRY, that detail can and should in the end stay at the workstream level , that said a good understanding of the issue and a recommendation by the DA on this particular case may prove useful now and as an example for the future.
To give an idea of impact : Adopting and applying a DRY approach would very likely reduce the values files by 50% or more (as some values as you can see are replicated many times and there are errors in that replication). It would also mean we can more faithfully comply with the outcome of DA *97 which is to test (well) what we release.
Follow-up:
The text was updated successfully, but these errors were encountered: