[FOLIO-1753] Replace mod-kb-ebsco with mod-kb-ebsco-java in snapshot and test environments Created: 29/Jan/19  Updated: 03/Jun/20  Resolved: 06/Feb/19

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

Type: Task Priority: P3
Reporter: John Malconian Assignee: John Malconian
Resolution: Done Votes: 0
Labels: ci, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones FOLIO-1727 SPIKE: select particular implementati... Open
Relates
relates to FOLIO-1755 verify dependency resolution checking Closed
relates to OKAPI-661 Test effect of module renaming on Oka... Closed
Sprint: Core: Platform - Sprint 56
Story Points: 1
Development Team: Core: Platform

 Description   

Replace the ruby-based mod-kb-ebsco module with the java-based mod-kb-ebsco-java module in folio-testing and folio-snapshot environments.

Acceptance Criteria:

  • Older FOLIO releases (Q4, etc) should continue to include the ruby-based version of the module
  • Inclusion and successful build of folio-testing with the java-based module.
  • Inclusion and successful build of hosted folio-snapshot with the java-based module.


 Comments   
Comment by Jakub Skoczen [ 29/Jan/19 ]

Hongwei Ji Carole Godfrey John Malconian Wayne Schneider Adam Dickmeiss Guys, we have decide that the easiest way to fully deprecate the Ruby implementation of mod-ebsco-kb and replace it with the Java one is to bump the version number of the interface and the dependency in ui-eholdings. Carole Godfrey if you are going to create an issue for bumping the version number would you mind linking it here?

We are going to keep FOLIO-1727 Open open to come up with a generic solution for deprecation or other cases when a particular implementation should be used.

Comment by Carole Godfrey [ 29/Jan/19 ]

Jakub SkoczenHongwei JiJohn MalconianWayne SchneiderAdam Dickmeiss Thanks on all of this – so as I understand, my steps will be as follows:
(1)Confirmed later interface version in java module (done)- mod-kb-ebsco-java - eholdings version interface is at 1.0 https://github.com/folio-org/mod-kb-ebsco-java/blob/master/descriptors/ModuleDescriptor-template.json#L7.
mod-kb-ebsco ruby - eholdings interface version is at 0.1 https://github.com/folio-org/mod-kb-ebsco/blob/master/ModuleDescriptor.json#L7
(2)Do a release of mod-kb-ebsco-java version (done) – I created a PR for the release as follows:
https://github.com/folio-org/mod-kb-ebsco-java/pull/95 (note – version is 2.0.1 due to sonarcloud issue with pom file commented code)
(3)Update ui-eholdings dependent interface version to 1.0 https://github.com/folio-org/ui-eholdings/blob/master/package.json#L82 (currently at 0.1)
Below PR in prep for release
https://github.com/folio-org/ui-eholdings/pull/697
(4)Do a release of ui-eholdings with version 1.0
John Malconian and Hongwei Ji – I started a release of ui-eholdings v1.4.0 - Jenkins job is failing at dependency check
https://jenkins-aws.indexdata.com/job/folio-org/job/ui-eholdings/view/tags/job/v1.4.0/

As an added note – there is a new permission (kb-ebsco.all) that will be required of the diku_admin user to be able to access mod-kb-ebsco-java module.

Do I need a delay between steps 2 and 3 to insure mod-kb-ebsco-java is available?
Is there anyway for me to test the Java version with eHoldings in a deployed environment before deploying across the board? We have done a lot of testing against vagrant box so we are confident – just would be helpful to have opportunity for tests before deploy – thanks

Comment by Hongwei Ji [ 29/Jan/19 ]

Carole Godfrey, technically no delay is really needed between step 2 and 3 since 2 will publish the new MD and artifact. If you want to verify, we can deploy both versions (in EBSCO), so you can take a look.

Comment by Carole Godfrey [ 29/Jan/19 ]

Hongwei Ji that sounds good – created release for mod-kb-ebsco-java version – https://github.com/folio-org/mod-kb-ebsco-java/releases, working on eHoldings

Comment by Jakub Skoczen [ 30/Jan/19 ]

John Malconian Hongwei Ji is there anything that the platform team need to do here?

Comment by John Malconian [ 30/Jan/19 ]

We just need to update the folio-ansible testing and snapshot configurations to explicitly tell Okapi to implement the java-based module.

Comment by John Malconian [ 30/Jan/19 ]

Carole Godfrey I've got a test build of folio-snapshot available at: http://folio-snapshot-test.aws.indexdata.com

Check it out and let me know if we are good to go. If so, I'll merge my config changes.

Comment by Carole Godfrey [ 30/Jan/19 ]

Ok taking a look now – thank you John Malconian

Comment by John Malconian [ 31/Jan/19 ]

Carole Godfrey FYI. Because of the interface version bump, it appears that mod-kb-ebsco-java has replaced mod-kb-ebsco in the http://folio-snapshot.aws.indexdata.com environment.

I still need to merge those config changes I made to folio-ansible in order for the new kb-ebsco module to replace the old kb-ebsco module in folio-testing.

Comment by Hongwei Ji [ 31/Jan/19 ]

Ditto John Malconian, we tested it in EBSCO env using /install, yes, Okapi basically upgraded the kb module for the tenant because of the version bump. Very neat and clean.

Comment by Carole Godfrey [ 31/Jan/19 ]

Ok thanks for letting us know and your help with setting up John Malconian – Is that the only site at this point?
Will http://folio-snapshot-stable.aws.indexdata.com and folio-testing not get updated until config changes in ansible?

Comment by John Malconian [ 31/Jan/19 ]

folio-snapshot-stable is essentially an instance of folio-snapshot that has passed UI integration tests. That hasn't happened in a couple of weeks, but could happen at any time, but they the same build configuration. folio-testing will not get updated until config changes are made. Unlike folio-snapshot, folio-testing explicitly specifies which modules are deployed.

Comment by John Malconian [ 06/Feb/19 ]

Merged changes to folio-ansible master that includes mod-kb-esbco-java in folio-testing environment.

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