Configuration problem on sync demo servers

Tags: #<Tag:0x00007efd1a42ca70>

(Tomasz Mueller) #1

Hi, We are having some problems with applying new configuration on sync demo servers: It seems that every attempt of configuration change is being rejected Can this be a side effect of fix? @wyclif, @dkayiwa

Regards, Tomasz

(Wyclif Luyima) #2

I doubt, the change for SYNC-271 is one on the page for viewing audit messages while the issue you are running is when you are loading configurations, I see no way they can be related, will look into it though.

(Wyclif Luyima) #3

FYI, they are running a released version (1.3.0) of the sync2 module and the fix for SYNCT-271 was committed after that release so it can’t be the cause of the issue, has to be something else. Have you tried restarting them?

(Tomasz Mueller) #4

Thanks, @wyclif for your investigation The problem is we have no ssh access to those servers, so we are limited in our options of solving this problem. Can anyone grant us the access? As far as I remember, @raff used to have the access.

Thanks, Tomasz

(Daniel Kayiwa) #5

Did you try to create a helpdesk request?

(Cintia Del Rio) #6

I need a link to the build before I can have a look.

(Tomasz Mueller) #7

Hi, @cintiadr

We are using build for deployment to the test servers.

Regards, Tomasz

(Cintia Del Rio) #8


It appears that the 3 red builds you had nothing to do with the sync servers. They are red in the ‘Build’ job, task ‘Build and push docker image’, specifically when pushing the image to dockerhub. All three red builds ran in the ‘yak’ agent.

So the question is: was yak broken or dockerhub had some problems? Hard to tell. We can see that yak was able to push a new image, so I assume the problem was solved. And most likely than not, the problem was dockerhub.

It’s a little bit hard to guess what happens unless we follow the logs.

Sync 2.0 Sprint 12 review - conflict resolution
Sync 2.0 Sprint 10 and 11 review - FHIR/Sync module extensions to support additional entities
(Tomasz Mueller) #9

@wyclif, @dkayiwa Is there a way to restart those servers without ssh access?

Regards, Tomasz

(Rafal Korytkowski) #10

@tmueller, running restarts all servers (no need to ssh).

(Wyclif Luyima) #11

You need ssh access from what I know, myself I dont have it

(Robby O'Connor) #12

s/servers/service/g – I don’t think it restarts the server, but it does recreate/restart the docker container

(Rafal Korytkowski) #13

@r0bby, correct. I meant it restarts OpeMRS instances, which is all what should be needed.