[FOLIO-1665] Build FOLIO Q4 release systems Created: 19/Dec/18  Updated: 03/Jun/20  Resolved: 11/Jul/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, q4-2018
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original estimate: Not Specified

Attachments: Text File UI_Tests_2019010901.txt    
Issue links:
Blocks
is blocked by MODCAT-97 No artifacts available in v1.1.0 release Closed
is blocked by MODVEND-68 No release artifacts for mod-vendors ... Closed
is blocked by STCOM-436 Search button doesn't display correct... Closed
is blocked by UICAT-47 Incorrect okapiInterfaces version str... Closed
Relates
relates to STCOR-304 Unable to locate some stripes-* modul... Closed
relates to UXPROD-1508 Populate reference data as part of in... Closed
Sub-tasks:
Key
Summary
Type
Status
Assignee
FOLIO-1679 Add mod-erm-usage reference and sampl... Sub-task Open  
Sprint:
Development Team: Core: Platform

 Description   

Build two, distinct FOLIO instances utilizing platform-core (core modules) and platform-complete (all modules).



 Comments   
Comment by John Malconian [ 19/Dec/18 ]

folio-q4-core.aws.indexdata.com has been built. It is based on q4-2018 branch of platform-core. Zak Burke has reported an issue that will necessitate a new, patch release of stripes-components (v4.5.1) and a possibly subsequent patch release of stripes (v1.1.1).

Comment by John Malconian [ 19/Dec/18 ]

released v1.2.0 of platform core. created q4-2018 release branch of platform-complete.

Comment by John Malconian [ 20/Dec/18 ]

released v1.2.1 of platform-core. contains stripes-components 4.5.1 mod-vendors release v1.0.3. updated platform-complete.

Comment by John Malconian [ 20/Dec/18 ]

getting the following error enabled mod-erm-usage for tenant:

0 Dec 2018 17:59:03:537 INFO  TenantAPI [85159eqId] sending... postTenant for diku
20 Dec 2018 17:59:03:540 INFO  PostgresClient [85162eqId] DB config read from environment variables
20 Dec 2018 17:59:03:552 INFO  PostgresClient [85174eqId] postgreSQLClientConfig = {"database":"okapi_modules","password":"...","port":5432,"username":"folio_admin","maxPoolSize":5,"host":"10.36.1.15"}
20 Dec 2018 17:59:03:669 INFO  BaseSQLClient [85291eqId] Creating configuration for 10.36.1.15:5432
17:59:04 ERROR PostgreSQLConnection Error with message -> ErrorMessage(fields=Map(Line -> 307, File -> auth.c, SQLSTATE -> 28P01, Routine -> auth_failed, V -> FATAL, Message -> password authentication failed for user "folio_admin", Severity -> FATAL))
17:59:04 ERROR PostgreSQLConnection Error on connection
com.github.mauricio.async.db.postgresql.exceptions.GenericDatabaseException: ErrorMessage(fields=Map(Line -> 307, File -> auth.c, SQLSTATE -> 28P01, Routine -> auth_failed, V -> FATAL, Message -> password authentication failed for user "folio_admin", Severity -> FATAL))
Comment by John Malconian [ 20/Dec/18 ]

mod-erm-usage sets some DB default environment variables in its Dockerfile:

DB_HOST
DB_PORT
DB_USERNAME
DB_PASSWORD
DB_DATABASE

It's possible that these are conflicting with the old style environment variables that are set in Okapi. e.g. db.host, db.port, etc. Since RMB supports both and since the '.' style is deprecated, I've updated the folio-ansible role, okapi-tenant-deploy, to set the DB variables using the more correct '_' style. This should, in effect, overwrite the defaults set in the module's Dockerfile.

Comment by John Malconian [ 20/Dec/18 ]

The change above resolves the issue with mod-erm-usage, however, now the mod-licenses container fails to initialize correctly with the error:

2018-12-20 19:28:30.199 ERROR --- [           main] o.a.tomcat.jdbc.pool.ConnectionPool      : Unable to create initial connections of pool.

org.postgresql.util.PSQLException: Connection to localhost:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.

So this looks like a DB setting issue with this module (and probably mod-agreements as well). Will perhaps need to specify these DB parameters as a container runtime option.

Comment by John Malconian [ 20/Dec/18 ]

actually mod-agreements starts up fine with the parameters DB_HOST, DB_PORT, etc set in the environment. mod-licenses does not which would indicate that the two modules behave differently in this regard. It's possible that mod-licenses only utilizes the db.* env parameters.

Comment by John Malconian [ 20/Dec/18 ]

steve.osguthorpe Ian Ibbotson (Use this one) I’m running into an issue attempting to pass data source (db) parameters to mod-licenses as environment variables. For example, setting either db.host or DB_HOST as an environment variables works fine for mod-agreements but seems to have no effect with mod-licenses which tries 'localhost' no matter what is set. Is it because localhost:5342 is hardcoded here? https://github.com/folio-org/mod-licenses/blob/e3d1c5733ca3203c9dd7c3a9bd263652058b0265/service/grails-app/conf/application.yml#L137

Comment by John Malconian [ 21/Dec/18 ]

First build of the full Q4 release is up at: http://folio-q4.aws.indexdata.com. Licenses has been disabled for now until the issue described above is resolved. Marccat is also notably missing.

Comment by John Malconian [ 21/Dec/18 ]

Just noticed that plugin-find-vendor is missing.

Comment by David Crossley [ 21/Dec/18 ]

I added ui-plugin-find-vendor-1.2.0 to platform-complete stripes-install.json (which is the latest release and that declared in the Q4 spreadsheet).

However following subsequent folio-install single-sever.md okapi seems to not find the descriptor in the registry. Only for 1.1.0 version.

Comment by John Malconian [ 21/Dec/18 ]

Thanks, David Crossley Looks like artifacts were not generated for plugin-find-vendor 1.2.0. I ran the release job and artifacts have been generated. Also ran the job for mod-licenses 1.0.2.

Comment by John Malconian [ 21/Dec/18 ]

Also need to add sample data from the mod-erm-usage repo to the ansible playbook.

Comment by John Malconian [ 02/Jan/19 ]

New Q4 build today. STCOM-436 Closed has been resolved. plugin-find-vendor included in release build. Still outstanding:

  • Sample data for mod-erm-usage
  • Marccat frontend and backend modules
Comment by John Malconian [ 07/Jan/19 ]

TODO: marccat is ready to be added to the release build. Update ui-agreements to v1.2.1.

Comment by Zak Burke [ 07/Jan/19 ]

TODO: update platform-core's test directory with changes from the snapshot branch.

Comment by Zak Burke [ 07/Jan/19 ]

TODO: update platform-core/package.json to include additional dependencies per the stripes framework guide;

    "react": "~16.6.0",
    "react-dom": "~16.6.0", 
    "react-redux": "~5.1.1", 
    "redux": "~3.7.2"
Comment by Zak Burke [ 08/Jan/19 ]

TODO: update platform-core/package.json to include new ui-users release, v2.19.0.

Comment by Zak Burke [ 08/Jan/19 ]

TODO: update platform-core/package.json to include bug-fix ui-inventory release, v1.5.2.

Comment by John Malconian [ 08/Jan/19 ]

Zak Burke

"react": "~16.6.0",
"react-dom": "~16.6.0",
"react-redux": "~5.1.1",
"redux": "~3.7.2"

Should these deps be explicitly added to platform-complete as well?

Comment by Matthew Jones [ 08/Jan/19 ]

Should these deps be explicitly added to platform-complete as well?

Unfortunately, yes. Although platform-complete includes them via platform-core as a dependency, only dependencies defined in the root package.json of an install can officially fulfill the peerDependency needs of packages within.

While things have and will probably continue to work without them in the root of platform-complete, there is no guarantee the intended peerDependency versions will get selected during install. Its one of those issues that, should it surface, will choose to do so when we least expect it!

Comment by John Malconian [ 09/Jan/19 ]

Roger that Matthew Jones.

Latest Q4 release build is available:

  • Inclusion of Marccat modules
  • ui-agreements upgrade to 1.2.1 (and subsequent downgrade to 1.1.1)
  • ui-users upgrade to 2.19.0
  • ui-inventory upgrade 1.5.2

TODO: (md331 has released another version of ui-agreements (1.1.2) that should be included in the next build.

Comment by John Malconian [ 09/Jan/19 ]

100% success for the UI integration tests against the current build of folio-q4-core. Results attached. Nice work Zak Burke

UI_Tests_2019010901.txt

Comment by John Malconian [ 11/Jan/19 ]

A new Q4 build is up at http://folio-q4.aws.indexdata.com - Changes include updated ui-checkout (1.5.0) and ui-requests (1.6.0) as well as a configuration fix for mod-marccat. I’ve filed a separate bug in Jira for a missing interface dependency declaration in ui-marccat (related to David’s comment above). https://folio-org.atlassian.net/browse/MODCAT-101

Comment by John Malconian [ 11/Jan/19 ]

TODO: upgrade ui-agreements to 1.1.3

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