Bamboo Build Failure Due to Platform Upgrade

Software
21

@cintiadr created a ticket here

22

see PR

23

@cintiadr , now that that PR is merged , is there any more work to be done ,to have the qa-server up again ,apart from re-running the bamboo deployment plan ??

24

Ansible changes is not deployed automatically. I will roll it out now.

My question is: now that we changed the SDK to generate the correct data and fixed our servers, shouldnā€™t we delete the liquibase changes? As this is a problem with the original data.

1 Like
25

I think its still relevant for implementers who may run OpenMRS the Enteprise way , that is people who dont use the SDK or the standalone .

26

Well done @cintiadr. Our qa-server is now up again :grinning:

27

So if I understand what @burke is suggesting, itā€™s the same thing I am suggesting. That we donā€™t do the liquibase change, unless thereā€™s any reason to say that this needs to be done for existing OpenMRS instances. I still donā€™t know if thatā€™s the case, it seems a little bit odd.

1 Like
28

Thats true @cintiadr.

so @dkayiwa should we go ahead and revert that commit ??

29

@mozzy have you tested to confirm that a new platform install has an admin account with a username, when you do not have that commit?

30

Not yet ,i still have several issues to debug and resolve at the moment that i have discovered from the qa-server , after the platform upgrade,

may be @ruhanga can look at this for now ,since its his area :slightly_smiling_face:

31

@dkayiwa, @mozzy, the fix on the SDK looks good to me. Iā€™ve been testing with fresh instances of the platform having the reverted change set, using the SDK and irrespective of the platform version, the admin user name is assigned to the systemID of admin. Looks like we are fine to revert the liquibase change set.

32

@ruhanga how about those who are not using the SDK?

33

Thanks for this @dkayiwa, Iā€™m not sure if I clearly understood the motivation behind reverting the change set (keeping the original data consistent since there is a fix in the SDK). This will definitely affect those not using the SDK. So this now gets a little bit not clear to me whether to revert the liquibase change set or not. :confused:

34

I would keep the liquibase change-set for those not using the SDK in-order to be sure we donā€™t break things. I would make sure that the changeset has the required <preCondition/> to prevent overwriting changes from the SDK.

1 Like
35

Ideally That was my innitial thought , because the changeset has a pre-condition , if the user name ā€œadminā€ exists it doesnt run , hence i also didnt see a necessary reason for the revert.

The whole cause of this thread was that , that change set couldnt run on our test enviroments , but we now corrected that. So i dont see the revert necesarry

36

Hi all,

For consistency across deployment environments in regards to the admin username being assigned to the systemId of admin, we will maintain the change set as discussed in todayā€™s PM call. Unless there are any issues preventing the maintenance of the change set, perhaps an improved design approach thatā€™d consider non SDK users, Iā€™ll go ahead to release the platform with it not later than Tuesday 28th January.

1 Like
37

@dkayiwa @mozzy @cintiadr am creating an openmrs distro instance with Reference Application 2.11.0-SNAPSHOT but am still getting this issue Error executing SQL UPDATE `users` SET `username` = 'admin' WHERE system_id='admin': admin user account is locked . My openmrs sdk version is OpenMRS SDK 3.13.6. Here is the full error log INFO 11/17/20 10:32 PM:liquibase: Reading from `liquibasechangelog`SEVERE 11/1 - Pastebin.com

38

@jecihjoy can you do a new sdk setup and share the log?

39

@dkayiwa I have run this command mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:setup-sdk and created a new openmrs distro instance but still the same error

40

Can you share the full log from when you run the sdk setup?