[FOLIO-1632] Create lighter-weight folio core VM Created: 28/Nov/18  Updated: 03/Jun/20  Resolved: 21/Jan/19

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

Type: Task Priority: P2
Reporter: Matthew Jones Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: ci, platform-backlog, sprint52, sprint53, sprint54, sprint55
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks STCLI-15 Dynamic Okapi module installation Closed
blocks STCLI-114 CLI support for local backend modules Closed
Relates
relates to FOLIO-1633 Establish scheme for declaring additi... Open
relates to FOLIO-1730 Create folio/minimal Vagrant box Open
relates to FOLIO-1548 SPIKE: a lighter-weight folio/testing... Closed
Sprint:
Development Team: Core: Platform

 Description   

Following up on the FOLIO-1548 Closed spike, we will need to regularly create and publish a new core Vagrant box containing the core FOLIO modules. This will enable front-end developers to use the CLI to provision a back-end for a given platform-* using the lighter-weight core VM as a base.

This draft CLI backend guide covers the initial STCLI-15 Closed workflow and will be expanded to support more back-end use-cases such as STCLI-114 Closed .

Differences with today's folio/testing-backend:

  • Front-end module descriptors that come preregistered must include the "requires" array of interfaces.
  • From comments in FOLIO-1548 Closed , the "core" build may be more like a "snapshot" build.
  • Additional backend modules to include? Reading the comments, this question may have been left open.


 Comments   
Comment by Wayne Schneider [ 21/Jan/19 ]

"core" Vagrant boxes are now being published as folio/snapshot-backend-core and folio/snapshot-core.

Comment by Matthew Jones [ 22/Jan/19 ]

Thanks Wayne Schneider

While testing snapshot-backend-core with platform-erm, I've run into some issues. The first of which I am hoping is a simple fix. For example when I attempt to simulate platform-erm's install with the CLI, I receive an error from Okapi:

install: can not enable folio_agreements-1.3.100039 due to missing dependencies or conflict

$ stripes mod descriptor stripes.config.js | stripes mod install --simulate
  stripes-cli:okapi ---> POST http://localhost:9130/_/proxy/tenants/diku/install?simulate=true&deploy=false&preRelease=true +0ms
  stripes-cli:okapi <--- 400 Bad Request +476ms
install: can not enable folio_agreements-1.3.100039 due to missing dependencies or conflict

I've traced this issue down to the following module descriptors that no longer appear to be in use. They provide an interface ("erm") that is also provided by mod-agreements.

mod-erm-1.0.0-SNAPSHOT.11
mod-erm-1.0.0-SNAPSHOT.10
mod-erm-1.0.0-SNAPSHOT.8
mod-erm-1.0.0-SNAPSHOT.7
mod-erm-1.0.0-SNAPSHOT.6
mod-erm-1.0.0-SNAPSHOT.5
mod-erm-1.0.0-SNAPSHOT.4
mod-erm-1.0.0-SNAPSHOT.2

Removing these descriptors from the VM will allow the simulate install command to continue (actual install failing later for other reasons which I am currently debugging), but a subsequent pull from the remote registry will restore them to the VM. Should these descriptors be unpublished from the http://folio-registry.aws.indexdata.com registry? Do you know of a proper way for handling conflicts like this?

Comment by Wayne Schneider [ 22/Jan/19 ]

If mod-erm is deprecated, we should remove the mod descriptors...what do you think, John Malconian?

Comment by John Malconian [ 23/Jan/19 ]

Yes. I've removed the 'mod-erm' MDs from the registry.

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