[FOLIO-1759] Create folio-ansible roles for deploying edge modules in reference environments Created: 30/Jan/19  Updated: 03/Jun/20  Resolved: 17/Feb/19

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

Type: New Feature Priority: P3
Reporter: Wayne Schneider Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: ci, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-1630 include "edge" modules in daily snaps... Closed
blocks FOLIO-1747 include edge-oai-pmh in folio-snapsho... Closed
blocks FOLIO-1748 include edge-rtac in folio-snapshot/t... Closed
blocks FOLIO-1749 include edge-patron in folio-snapshot... Closed
blocks FOLIO-1750 include edge-orders in folio-snapshot... Closed
Relates
relates to EDGCOMMON-18 Change API key delimiter to something... Closed
Sprint: Core: Platform - Sprint 56, Core: Platform - Sprint 57
Story Points: 5
Development Team: Core: Platform

 Description   

Roles need to be created in folio-ansible for provisioning edge modules separately from standard Okapi modules. One possible approach:

  • Update the security settings for our environment builds to expose edge modules on an external port (any opinions about what port?)
  • Create a role in folio-ansible to set up nginx as a load balancer in front of the edge modules (could be container or host-based...given the configuration flexibility required, I would suggest that host-based would be more convenient)
  • Create a role in folio-ansible to deploy and configure edge modules.

The edge module role would need to:

  • Query Okapi to determine the dependencies of the edge module, then deploy and enable those dependencies for the tenant
  • Pull the Docker image for the edge module, configure, and deploy (outside Okapi), assigning a port
  • Configure nginx to proxy for the edge module
  • Enable the edge module for the tenant and assign permissionSets to admin user (assuming there may be permissionSets that need to be loaded)

Hongwei Ji David Crossley any thoughts on what I'm missing?



 Comments   
Comment by Hongwei Ji [ 30/Jan/19 ]

Wayne Schneider looks good. Edge modules do not have perm defined because they live outside of Okapi. The modules they depend on have perm defined. But those perms will be assigned to the new institution user, not admin user since edge API key is tied to the institution user not admin user. Of course, we can make things simpler by letting admin user to play both roles.

Comment by Wayne Schneider [ 07/Feb/19 ]

Ran into an issue with the "institutional user" required by edge modules: my original plan was just to use the default admin user (diku_admin) as the institutional user, but unfortunately the edge-common library doesn't allow for an underscore in the IU username. Craig McNally is writing tickets to update the library to remove this limitation (see the linked stories for more detail).

It is probably a better practice to create an IU specifically for edge modules, but that complicates completing the edge-module role.

Comment by Wayne Schneider [ 12/Feb/19 ]

Plays have been added to the role to create the institutional user. All that remains is to update the Vagrantfile and AWS network config to expose port 8000.

Comment by Wayne Schneider [ 12/Feb/19 ]

EDGCOMMON-18 Closed is resolved, but none of the current edge modules have upgraded to the new version of the edge-common library. This makes it a little harder to test. I've blocked the related issues against the issues for upgrading the edge modules.

Comment by Wayne Schneider [ 17/Feb/19 ]

Adam Dickmeiss suggested a different approach, using Okapi to manage the Docker containers and proxy the edge endpoints as the supertenant. There are some advantages and disadvantages to this approach.

Pros:

  • No need to expose an additional port on the target system
  • No need to rely on an additional piece of software (nginx) for proxying
  • No need to track port usage for the edge module containers, as Okapi will just take care of it
  • No need to manage containers outside of Okapi deployment

Cons:

  • Greater possibility of path conflicts
  • Edge module module descriptor dependencies are described from the perspective of the target tenant, not the supertenant – so while the edge module edge-oai-pmh requires the oai-pmh interface provided by mod-oai-pmh, the supertenant doesn't need to have that module enabled, only the target tenant. This also creates the possibility of multiple versions of the required modules being deployed, if the version preferred by the tenant is not the "latest" version as defined by the Okapi installation.

Either approach would work for our reference environments. At this point it's probably not worth redoing the roles for the convenience of using Okapi to proxy the edge modules, but it's worth documenting the alternative approach here.

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