Starting this thread as I didn’t see another option; LMK if I should post elsewhere.
Update provided to the PM Team this Monday: The platform 2.4 release is no longer blocked by needing to address the standalone build but this will be addressed in a subsequent minor version update. This means that this week @gcliff will put together the alpha for other implementers/volunteers to test.
QA Plan
@gcliff presented to the TAC last week that in addition to the existing tests running alongside the builds, the primary method of testing at the moment has been this suite of manual API queries:
or REST-WS module we are using this google sheet(Platform 2.4.0 REST-WS endpoint tests - Google Sheets ) to log testing activities. Later, data from the sheet will be used to develop an automated rest endpoint testing system and we will deprecate the manual testing of rest endpoints for future releases. We are only proceeding with the manual testing due to time constraints and absence of an established end to end rest-endpoint testing system for platform releases.
Anything to add to that @gcliff?
@gcliff can you just confirm - is this the list or search query you’re using in Jira to track the remaining work, or is there another place in Jira you’re using? Issue navigator - OpenMRS Issues
The guidance from the TAC call was as follows:
Make sure RefApp 2.11 starts & runs on platform 2.4 - @gcliff, who is owning this?
QA environment running platform 2.4 that people can try the RefApp against - @gcliff this is what you’re working to get ready this week, right?
Testing that different setup workflows work
MariaDB and mySQL tests have errors - suggests possible issue with platform standing up against plain mySQL server; could block docker
Check that Implementers’ Distributions run with platform 2.4:
PIH to try to update their snapshot to run on platform 2.4 - matter of finding time if it doesn’t start (@mogoodrich can you post your findings here if/when you manage to do this? )
@mogoodrich and @ibacher you had voiced some concerns on the TAC call - can you express those here if they haven’t already been resolved or adequately captured above?
Thanks all, and huge kudos to Cliff for continuing to move this important work forward.
I actually tried running the PIH EMR against Platform 2.4 during the TAC and posted in the chat, but the error might have gotten lost… it was the same error that @ibacher was seeing in one of the tests, involving an issue with liquibase running.
@gcliff I was trying to fire up an existing PIH EMR instance/database against Platform 2.4… have we tried starting with an existing Ref App instance/database running against 2.3 and upgrading it to 2.4? (For reference, the PIH EMR currently runs using Platform 2.3).
If an existing Ref App DB from 2.3 starts up fine against 2.4 then I can try to probe a little further on PIH side… but as of now, it fails pretty early on in the startup.
Are you sure that’s true of RefApp 2.11 (as it currently is)? I ask this because I’ve run into issues running RefApp 2.11 on platform 2.4 because RefApp 2.11 doesn’t include a new release of the adminui with this fix.
There are two major issues I’m aware of:
During the TAC call, Mark tried to run the PIH EMR on 2.4.0 core and got an error which indicated that the new ChangeLogDetective class couldn’t figure out which set of changes corresponded to the baseline of the PIH EMR database. This is troubling because it indicates that our new Liquibase architecture may not actually work against real-life implementations of OpenMRS (we’ve certainly tested upgrading the RefApp).
If possible, it would be great to get @wolf involved in diagnosing and troubleshooting this issue (he originally wrote the Liquibase overhaul). This also suggests that we may want to try running other implementations on top of platform 2.4. They may fail because modules haven’t all been updated, by at least we should verify that the liquibase changes apply correctly.
I re-wrote the memory appender to support upgrading to log4j2 and I’m not entirely sure that I ever fixed all the code (in the installer pages, webservices, and legacy ui) to properly display messages from the new version of the memory appender. This means most of the places we try to display logging messages to the user simply won’t work. I’ll try to get that fixed this week.
@gcliff that’s a neat list view, thanks. This ticket below wasn’t showing up in your list though - looks like that was because it had a Fix Version label of “Core 2.4.0” instead of “Platform 2.4.0”. Should we change all tickets labelled with “Core 2.4.0” to “Platform 2.4.0”?
https://issues.openmrs.org/browse/TRUNK-5970
Thanks @ibacher for clarifying that you’ve tested the upgrading the Ref App. Let me know if you’d like me run it again and look for anything in particular.
I looked at the class you are mentioning at this comment does give me a little pause:
* Returns the version of the Liquibase snapshot that had been used to initialise the OpenMRS
* database. The version is needed to determine which Liquibase update files need to be checked for
* un-run change sets and may need to be (re-)run to apply the latest changes to the OpenMRS
* database.
… my fear here is that we have many different implementations running the PIH EMR that were launched at different times… so even if my SDK version (which was probably set up more recently than many of our production versions) did work, it doesn’t necessarily mean that the it will work against our production systems? It’s a bit of red flag if upgrade might work successfully against our staging/test environments but still fail against prod (or, worse, since it’s liquibase–really screw up the DB ). But I really haven’t looking into this at all so maybe I’m making it out to be riskier than it is.
Here’s the text from that chat; turns out we save them in the recesses of our Zoom service:
00:30:34 Ian Bacher: java.lang.IllegalStateException: identifying the snapshot version that had been used to initialize the OpenMRS database failed as no candidate change set resulted in zero un-run changes
00:39:58 Mark: I just got the same error that Ian did trying to start up the PIH using OpenMRS 2.4.x
00:40:12 Mark: ROR - Listener.contextInitialized(200) |2020-10-16T10:37:40,580| Failed to obtain JDBC connection
java.lang.IllegalStateException: identifying the snapshot version that had been used to initialize the OpenMRS database failed as no candidate change set resulted in zero un-run changes
00:42:50 Ian Bacher: IIRC in the SDK we have a work-around that loads an empty database first. We may need to move that from the SDK to the OpenMRS initialisation process.
00:43:21 Ian Bacher: (That way the logic to detect which set of liquibase changes to run works)
00:43:38 Mark: fwiw, I was trying to fire up an existing DB, not starting from scratch (which is obviously more of our use case)
00:44:25 Ian Bacher: oh… that’s actually worse bc it might indicate a flaw in the new liquibase architecture
00:52:39 Mark: my gut thought would be for someone to take an reference app 2.3 instance (maybe just one of the QA servers) and try to update that to 2.4 and then debug when they assumedly run into the issue
Cool… I will try to schedule in some time to take a look at this this week.
Also, for reference, all the PIH EMR instances were initialized with OpenMRS 1.9 or later, but some of our other instances (and many others) date back to way before that… it sounds like a testing nightmare if we have to test upgrading all previous versions of OpenMRS.
I’m hoping it’s not that bad, i.e., as long as it’s been upgraded to OpenMRS 1.9, the change set detective should be able to detect that it needs to start from that revision… At least that’s the hope!
@gcliff Can you add this commit into the current iteration of the platform release? It’s necessary for us to be able to display log messages in the UI.
@ibacher we have already done the release of the artifacts to maven for alpha, only pending announcing it to the community, may be we are going to have it in the coming beta release
)
). But I really haven’t looking into this at all so maybe I’m making it out to be riskier than it is.