[FOLIO-2265] Create preview namespace and Okapi for PR preview Created: 17/Sep/19  Updated: 03/Jun/20  Resolved: 01/Oct/19

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

Type: Task Priority: P2
Reporter: Ian Hardy Assignee: Ian Hardy
Resolution: Done Votes: 0
Labels: ci, devops, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-2066 CI architecture and process to allow ... Closed
Sprint: CP: sprint 73
Story Points: 1
Development Team: Core: Platform

 Description   

Create a new preview namespace on kuberenetes. This okapi will run the tenants for PR previews.

Components:

  • New namespace on CI kubernetes cluster (called preview)
  • New database/okapi running in preview namespace


 Comments   
Comment by Ian Hardy [ 24/Sep/19 ]

Created database for preview okapi plus deployment, service, and ingress. Need to bridge namespaces for the modules required to secure the supertenant in order to secure.

Comment by Ian Hardy [ 27/Sep/19 ]

Need to bridge namespaces for the modules required to secure the supertenant in order to secure.

^ My mistake, this is a very bad idea. I set up the second okapi this way and caused problems with the supertenant. The issue was overlapping DB between thew two okapi instances since the module schemas for supertenant_mod* share the same name. Instead, proceed by deploying a separate set of the modules required for auth using their own db for this namespace.

Practically speaking I can't think of any reasons outside of CI to have two different okapi clusters share a set of modules. But for CI and any other application it is critical that tenant ids are unique between the two okapis. This has to be managed by sysadmins since okapi of course will not force unique Ids against another okapi not in the same cluster.

As a side note, one way to fix this on k8s was:

1. spin up bastion host on cluster (used an ubuntu container and install the psql client)
2. login to rds database and check which modules are enabled:

 SELECT tenantjson from tenants WHERE tenantjson->'descriptor'->>'id' = 'supertenant';

3. Update excluding mod-authtoken from the list of enabled modules (be sure to use the current enabled modules not the values below)

UPDATE tenants
SET tenantjson = '{"enabled": {"okapi-2.32.0": true, "mod-login-6.0.0": true, "mod-users-15.6.1": true, "mod-permissions-5.8.1": true}, "descriptor": {"id": "supertenant", "name": "supertenant", "description": "Okapi built-in super tenant"}}'
WHERE tenantjson->'descriptor'->>'id' = 'supertenant';

4. restart or redeploy okapi
5. Follow the steps in the okapi guide to rebuild superuser accounts and credentials ending w/enabling authtoken through the okapi API as normal

Comment by Ian Hardy [ 01/Oct/19 ]

Would like to update the design to use a separate RDS instance for the preview Okapi's okapi database and module database (only for those modules involved in securing the supertenant). There are errors occuring when trying to enable modules because the roles that need to be created for the supertenant already exist.

Comment by Ian Hardy [ 01/Oct/19 ]
  • Created RDS instance for the preview okapi's okapi DB and for the modules involved in securing the supertenant.
  • secured supertenant
  • verified by creating tenant previewtest and enabling a module running in the okapi-default namespace (using an alias service to cross namespaces): https://okapi-preview.ci.folio.org/_/proxy/tenants/previewtest/modules
Generated at Thu Feb 08 23:19:24 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.