Looks like the first line of technical hurdles is cleared to get to inventory of all that is needed for an 1.0.0 alpha release of Ozone. A big chunk of the remaining effort is about releasing O3 alpha itself, see:
A bit of stalling on Ozone distro and Docker related tasks. Even though @achachiez made some progress already until yesterday, he is now stuck on internal projects until tomorrow (Thu).
The objective is to have Ozone Pro as of now up on the dev server by Monday.
@ruhanga to oversee the practical release of Ref App 3.0.0, starting with the backend, through being assigned RA-1994 (Release of Distro Ref App 3.0.0 (alpha)).
Elsewhere:
Ozone FOSS data extract reports now properly generated, @reagan to test that they can be imported easily into Superset.
Thanks to a lot of work by @jnsereko the O3 automation test strategy is moving ahead. He’s currently ~60% done Quality Gates 1 and 3 as described here: O3 Release Process: Diagram for review
Yes, QA is primarily focused on what makes Ozone what it is, therefore all aspects that touch the integration between the components.
But of course this will often spill to validating that the components themselves behave how they should, and that’s mostly O3 (since the other components are very stable).
A good example of this spilling is the following.
While testing Ozone Analytics, we realised that there was no allergies in our flattened datasets, that simply came from the fact that the form to record allergies is broken in O3.
We have an issue with Debezium that intermittently stops working after a short while, this is what @achachiez is focusing on right now. This is a little nasty as it seems to not happen locally but does happen once deployed on AWS.
Unfortunately this is slowing down most of our QA process, since the whole integration layer can’t be tested, at least online.
(Ozone Pro) Otherwise Emmanuel had fixed all HTTPS-related issues that we had behind the proxy, as well as the issue with Odoo not loading its OIDC settings. All good there now.
Elsewhere (still roughly the same):
@mksrom and will work the way to have this perfectly hooked to all necessary CI/CD processes.
The QA process has actively resumed between @enochb and @nuhuhmutebi and we are gathering feedback as it goes. A configuration issue has been identified in regards to the ERP integration, Nuhuh is defining the issue fully before attempting to address it.
Elsewhere:
@mksrom and @achachiez will work the way to have bleeding edge deployments perfectly hooked to all necessary CI/CD processes.
@ruhanga is also putting together an Ozone Pro backend config to have a Liquibase configuration that creates a ‘service-account-eip’ user automatically.
@enochb will start QA on Ozone FOSS data extract process, @nuhuhmutebi to brief him.
We are refining the design thinking on our automated QA process for Ozone to probably be purely REST/web API-based, as suggested by @ibacher; which aligns with the actual mission of Ozone: be an orchestration of integrations.
(Ozone Pro only) We uncovered an issue with the TTL of OAuth tokens, this was temporarily fixed by @achachiez by setting a long TTL in Keycloak, but otherwise this ticket should be used to fix the issue:
EIP-120: OAuth token to be renewed at least 10 seconds before expiration
PR here - @wyclif it would be great if you could review it.
Otherwise we are still going through the inventory of all that it takes to release Ozone, and there is a bunch of things on top of what is needed to release O3 Ref App, among others:
(Ozone Pro only) Not a blocker for the alpha release (but it is a blocker for the beta) but we see intermittent issues with having two concurrent instances of Debezium consuming OpenMRS’s MySQL bin log. @achachiez is on it with two scenarios at hand:
We are missing a config somewhere to tell both Debezium instances that all is ok and that each one should expect a companion.
We should get rid of one of them - easier said than done. This could take us in ensuring that openmrs-eip can feed from either Debezium or Kafka, there would be work to do there.
Elsewhere:
Moving forward with RA-1994 and in particular the release of
The team at Mekom keeps on with QA-ing Ozone. An issue has been found with a misalignment between OCL concepts defining the dispensing and dosing units and Odoo configuration for the UoM, @nuhuhmutebi is looking into it.
Elsewhere:
RA-1994: All Ref App 3.x Maven artifacts have been released
A lot was done over the past 10 days in advancing the alpha release process of Ozone. We have released almost all Ozone-specific artefacts (that are not O3 artefacts):
After that the release process of Ozone will only hinge on that of O3, @ibacher@grace@raff → . Specifically the frontend release of O3 (since the backend release is ready to go). So readers should rather follow:
kudos for that one 
After that the release process of Ozone will only hinge on that of O3, @ibacher @grace @raff → 
. Specifically the frontend release of O3 (since the backend release is ready to go). So readers should rather follow:
Ozone 1.0.0-alpha.1 Released