[FOLIO-3025] Add mod-ebsconet to testing/snapshot hosted environments Created: 18/Feb/21  Updated: 04/Mar/21  Resolved: 04/Mar/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Story Priority: P3
Reporter: Max Shtanko Assignee: David Crossley
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: File ftt-120-okapi.log.gz     File mod-ebsconet-local-check.mp4     Text File snapshot-core.txt    
Issue links:
Blocks
blocks MODEBSNET-1 Project setup in GitHub: mod-ebsconet Closed
blocks MODEBSNET-5 Define retrieve and update ebsconet ... Closed
Relates
relates to FOLIO-2985 Create mod-ebsconet github repository... Closed
relates to FOLIO-3040 Failure adding springway modules refe... Closed
Sprint: DevOps Sprint 109, DevOps Sprint 108
Development Team: FOLIO DevOps

 Description   

There is a new mod-ebsconet (https://github.com/folio-org/mod-ebsconet) module that we'd like added to the hosted environments for testing and demo purposes.



 Comments   
Comment by David Crossley [ 22/Feb/21 ]

I did try adding this to folio-testing-test build today, but Okapi failed to deploy it.

Have you verified that mod-ebsconet can be deployed using a VM?
See https://dev.folio.org/guides/install-backend-module/#ensure-local-docker

Also see your setup ticket FOLIO-2985 Closed , especially the problem that is reported by "api-lint".

Comment by Max Shtanko [ 25/Feb/21 ]

Hi David Crossley,

I fixed all "api-lint" reported issues and successfully deployed using a VM locally. Can you please confirm that there are no pending issues from the development team (ThunderJet) is blocking the module to be deployed on the environments? Thank you.

Comment by David Crossley [ 26/Feb/21 ]

I did try again today. However it failed to deploy. See FOLIO-3040 Closed .

There was the same trouble with installing two other modules ( FOLIO-3030 Closed and FOLIO-3031 Closed ). Not sure yet if there is some common issue with these three modules, or with the infrastructure in general.

To assist with debugging FOLIO-3040 Closed , would you please indicate which VM and version was successful for your local test.

Comment by Max Shtanko [ 26/Feb/21 ]

Vagrant box version: 5.0.0-20210113.5664
Virtual box version: 6.1.16 r140961 (Qt5.6.3)

Comment by Victoria_Smelova [ 26/Feb/21 ]

David Crossley Jakub Skoczen 
Please, let us know if anything else is required from Thunderjet to speed up the resolution of this issue.
We'd like have the module available on testing/snapshot hosted envs to verify stories before sprint closure on Monday.

Comment by David Crossley [ 27/Feb/21 ]

I did try again today with folio-testing-test and folio-snapshot-test Jenkins builds.

The situation is the same. It still does not start, and has the same "timeout" issue as described at FOLIO-3040 Closed .

The developers of mod-data-export-spring had similar startup troubles. They made some code improvements, and now it does start properly (see FOLIO-3030 Closed ). Perhaps it will help for you to discuss with them.

Comment by Max Shtanko [ 02/Mar/21 ]

Hi David Crossley,
I did changes according to the required changes from successfully deployed projects. Please can you validate the deployment? Thank you.
P.S. I replayed the same yesterday directly in teams chat with some additional details.

Comment by David Crossley [ 02/Mar/21 ]

Have you been successful with a local VM? For example with folio/snapshot-core

Comment by Max Shtanko [ 02/Mar/21 ]

Yes.

Maxs-MBP:testing-with-ui NorthWind$ vagrant box update

==> default: Checking for updates to 'folio/testing'

    default: Latest installed version: 5.0.0-20210113.5664

    default: Version constraints: 

    default: Provider: virtualbox

==> default: Updating 'folio/testing' with provider 'virtualbox' from version

==> default: '5.0.0-20210113.5664' to '5.0.0-20210301.5937'...

==> default: Loading metadata for box 'https://vagrantcloud.com/folio/testing'

==> default: Adding box 'folio/testing' (v5.0.0-20210301.5937) for provider: virtualbox

    default: Downloading: https://vagrantcloud.com/folio/boxes/testing/versions/5.0.0-20210301.5937/providers/virtualbox.box

The version I tested was 5.0.0-20210113.5664.

Comment by David Crossley [ 02/Mar/21 ]

As explained in FOLIO-3040 Closed that VM is way too old. Please use folio/snapshot-core recent.

Comment by David Crossley [ 02/Mar/21 ]

Updated documentation to assist:
https://dev.folio.org/guides/install-backend-module/#ensure-recent-local-vm

Comment by David Crossley [ 03/Mar/21 ]

I did try yet again today. See attached logfile ftt-120-okapi.log.gz which are the same as i see when adding this module to my local folio/snapshot-core VM build.

The issues are the same as before "Timed out after waiting 300000(ms) for a reply. address: __vertx.reply.42"

Comment by Max Shtanko [ 03/Mar/21 ]

Hi David Crossley,

I was able to successfully test the module locally with folio/snapshot-core recent, but I've encountered connection-refused issues with building the module as a Docker image.

Can you please assist me with the current Dokerfile configuration? 

I made Dockerfile reconfiguration to keep as much similar to successfully deployed modules from your references. 

Regarding the error message you provided. I see several (in fact over 200) errors prior to the one you mentioned, including:
2021-03-02T23:26:38,811 ERROR HttpResponse HTTP response code=404 msg=No suitable module found for path /authn/login for tenant supertenant
2021-03-02T23:29:36,547 INFO ProxyContext 519399/proxy RES 404 191us okapi mod-ebsconet-1.0.0-SNAPSHOT.9
2021-03-02T23:29:36,547 ERROR HttpResponse HTTP response code=404 msg=mod-ebsconet-1.0.0-SNAPSHOT.9
2021-03-02T23:29:36,894 INFO ProxyContext 525270/proxy REQ 10.36.1.228:58814 supertenant GET /_/proxy/modules/mod-tags-0.8.1-SNAPSHOT.57 okapi-4.7.0

And one more thing to take a closer look:
2021-03-02T23:31:38,328 INFO TcpPortWaiting Try connect to service mod-ebsconet-1.0.0-SNAPSHOT.9 at 10.36.1.228:9171 count {COUNT_NUMBER} <- the count number is continuously rising until we get timeout error.
...
2021-03-02T23:35:17,965 INFO TcpPortWaiting Try connect to service mod-ebsconet-1.0.0-SNAPSHOT.9 at 10.36.1.228:9171 count 48
2021-03-02T23:35:27,196 INFO TenantManager job complete
2021-03-02T23:35:27,197 WARN TenantManager job failed
org.folio.okapi.util.OkapiError: Timed out after waiting 300000(ms) for a reply. address: __vertx.reply.42, repliedAddress: http://10.36.1.228:9130/deploy

This is the connection going to be ended with the timeout error and it starts from the very beginning of the log. What is trying to connect to the ebsconet module from the Okapi side as TenantManager and for what reason?  
Thank you for your time and assistance.

Comment by David Crossley [ 03/Mar/21 ]

I am sorry, but it is not my job to assist with development, and i do not know enough to advise.

There are many EPAM and EBSCO developers here, so you need to seek their assistance.

Comment by David Crossley [ 03/Mar/21 ]

Regarding my request in the earlier Jira comment to verify that the module will install, enable, and deploy.

That is not asking you to test your module code against the VM.

Instead it is asking you to verify that your currently published module docker image will deploy without error using that VM. We at FOLIO DevOps cannot proceed until that is happening.

I suggest that you follow those steps at https://dev.folio.org/guides/install-backend-module/#ensure-recent-local-vm
to verify another module, for example mod-data-export-worker. Then you will see successful deployment of a module container.

Yes, obviously there is something wrong with your dockerised module.

Comment by David Crossley [ 03/Mar/21 ]

Besides that, there is something else that is required. There needs to be an API endpoint that we can use to verify successful deployment, e.g.
https://dev.folio.org/guides/install-backend-module/#ensure-module-health-endpoint

Comment by Andrei Makaranka [ 03/Mar/21 ]

Hi David Crossley  ,

I found an issue in our configuration and successfully deployed the docker image "folioci/mod-ebsconet:1.0.0-SNAPSHOT.13" to the local vagrant box 'folio/snapshot-core'.

 

Could you please retry deployment of the mod-ebsconet?

Thank you in advance.

 

Deployed logs : snapshot-core.txt

Verification : mod-ebsconet-local-check.mp4
  
cc : Max Shtanko

 

 

Comment by David Crossley [ 03/Mar/21 ]

Hooray, that is working with the folio-testing-test Jenkins build.

Of course the health endpoint is not yet happening, but at least we get an error. That can come later.

Late here, but i will proceed with the configuration and rebuilding of some reference environments. Good to have it in ASAP.

Comment by David Crossley [ 03/Mar/21 ]

Are you able to say here on the ticket was the problem was? This could be a common mistake, and good to have a note here for seekers.

And thanks for doing the local test.

Comment by Andrei Makaranka [ 03/Mar/21 ]

Hi David Crossley,

Great news, thanks

The last issue was trivial - we missed port configuration on which our service need to be started.
For Spring Boot default is 8080, but for FOLIO the default port should be 8081
Do not forget to configure the port in application properties file server.port = 8081

Comment by Wayne Schneider [ 03/Mar/21 ]

Note that FOLIO does not require the port to be 8081, you can also configure the port in the module descriptor template. Here is an example from mod-circulation.

Comment by David Crossley [ 03/Mar/21 ]

Thanks Wayne. So yes they could simplify configuration.

In this case the issue was that they had 8081 in ModuleDescriptor and Dockerfile,
but the Spring application.yaml was missing that setting so was using the default 8080.

See pull/13

Comment by David Crossley [ 03/Mar/21 ]

Okay, so mod-ebsconet is now in folio-snapshot-load.

The other reference environment builds will include it on tonight's normal daily runs.

Comment by David Crossley [ 04/Mar/21 ]

There were delays in the reference environment builds today. But now all are re-built and mod-esconet is there.

Generated at Thu Feb 08 23:25:03 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.