Hi Juhan, Thanks for the help. It turns out that it’s was a minor database configuration issue.
Regards, Courage. On Fri, Nov 22, 2019 at 8:08 AM Juhan Aasaru <[email protected]> wrote: > Hi Courage! > > steps of Postman script can pass but this doesn't mean they actually worked > behind the scenes since the HTTP request just creates a command > and returns 202 but that commandt could fail during processing of it. > (idea for improvement - return command id and then use Postman to ask > using that id if the command failed or not > currently you can see if it failed from Cassandra database -> seshat -> > table command_source) > > If you have problems with database then check out step 03.1 (body of it) > maybe you pass wrong details about how to reach your databases. > > I remember you used IP addresses instead of DNS names. > In this case you should also set IP addresses to eureka.instance.hostname > for each micro service. > > So for example in case of customer micro service currently has: > eureka.instance.hostname: customer-ms > I think you should change that to: > eureka.instance.hostname: ${CUSTOMER_IP} > and so on for each micro service if you are using IP-s instead of hostnames > (although hostnames should work just fine with docker) > > What it does is that if a micro service starts it reports to Eureka > how to concat it. If the micro service reports its host/ip incrorectly > then Eureka > reports this incorrect address to others asking Eureka how to connect > to particular micro service and thre results is that no micro > service can connect to any other micro service. > > In order to verify if the configuration still works > I improved my integration_test.sh script and made it to > provision the system with set of micro services and then > run first half of provisioning (until step 08.5) using Newman > (this is the tool to run Postman scripts from command line). > It is designed so that it can be run from start to finish in one go > and if it passes without errors then we know that nothing has breaked. > > I was running it several times but on the last run Docker crashed again > and I couldn't verify > it ran successfully until the end (I had no more time left). > I had to adjust the pauses between steps because some of the provisioning > just takes more time - > especially provisioning a micro service means we have to wait for Flyway > to create > all the tables of that micro service. > > I reccommend for you to run the same script (it runs about 15min) and let > me know if it passed or not. > For this I suggest to clone a separate copy of fineract-cn-docker-compose > to some other folder as this way you don't have any local edits and also > integration test overwrites .env file (make a backup of it if you don't > create clean > clone for this one) > > I hope this helps. > > Kind regards > Juhan > > > > > > > > > > > Kontakt Courage Angeh (<[email protected]>) kirjutas kuupäeval R, > 22. november 2019 kell 00:24: > >> Hi Juhan, >> >> Yea I made sure the services are registered on Eureka. Actually Steps 01 >> to 07.021 completed successfully just step 07.022 produces an error. >> >> When you look at the logs it shows that it is a JDBC data source >> connection error so I am thinking it has to be related to database >> configuration. >> Can I see your logs for portfolio after completing step 07.022 and the >> description of your fineract cn portfolio container? >> >> P.S: I get this same error when using the bash scripts and the postman >> scripts. >> >> Regards, >> Courage. >> >> On Wed, Nov 20, 2019 at 1:59 AM Juhan Aasaru <[email protected]> wrote: >> >>> Hi Courage! >>> >>> I tried myself and in order to have a repeatable process I created (and >>> merged with few minor fixes) >>> >>> https://github.com/apache/fineract-cn-docker-compose/blob/master/integration_test.sh >>> I didn't manage yet to complete this however as for some reason the >>> Docker engine started >>> failing locally when I tried to provision everything. I try to look more >>> into this in coming days. >>> So unfortunately I couldn't yet repeat your problem. >>> >>> The "portfolio__v1__khepri permission" error suggests that not all the >>> micro services are registered with Eureka. >>> If a micro service wants to connect to other micro service it asks >>> Eureka for the IP/DNS of the other micro service. >>> Open up Eureka console at http://localhost:8761/ (or http://eureka:8761) >>> and check which micro-services are registered. All micro services except >>> provisioner should be there. >>> >>> Also I have had this error when the provisioning scripts used >>> wrong hostname for micro services. >>> So for Postman scripts see steps 02.01, 02.02... for the body of the >>> scripts as it contains the host of the micro service. >>> >>> I don't have any ideas about why Flyway is failing. >>> >>> Juhan >>> >>> Kontakt Courage Angeh (<[email protected]>) kirjutas kuupäeval T, >>> 19. november 2019 kell 18:21: >>> >>>> Yea, Juhan. >>>> I am using the latest docker images created 4 weeks ago. >>>> >>>> On Tue, Nov 19, 2019 at 2:52 AM Juhan Aasaru <[email protected]> wrote: >>>> >>>>> Hi Courage! >>>>> >>>>> Did you force Docker Compose to pull the latest images from repository? >>>>> >>>>> docker-compose rm -f >>>>> docker-compose pull >>>>> >>>>> Kind regards >>>>> Juhan >>>>> >>>>> Kontakt Courage Angeh (<[email protected]>) kirjutas kuupäeval >>>>> E, 18. november 2019 kell 19:34: >>>>> >>>>>> Hi Juhan, >>>>>> >>>>>> I am trying to do some updates to the fineract-cn-docker-compose bash >>>>>> scripts. Uhmm... I tried to enable portfolio__v1__khepri permission >>>>>> but I get this error >>>>>> `Error while processing command. FlywayException: Unable to obtain >>>>>> Jdbc connection from DataSource` >>>>>> >>>>>> I also tried it using the postman scripts you implemented I get the >>>>>> same error. >>>>>> I am not sure what is wrong. Here is the log file: >>>>>> https://pastebin.com/11vRW2wC for more information. >>>>>> >>>>>> P.S I made no changes to the docker configurations. >>>>>> >>>>>> Regards, >>>>>> Courage. >>>>>> >>>>>
