[FOLIO-2298] Configure Okapi in folio-preview namespace to access modules in folio-default namespace Created: 02/Oct/19  Updated: 03/Jun/20  Resolved: 15/Nov/19

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

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

Issue links:
Blocks
blocks FOLIO-2268 preview tenant/bundle creation for fe... Closed
Sprint: CP: sprint 74, CP: sprint 76, CP: sprint 73, CP: sprint 75
Story Points: 3
Development Team: Core: Platform

 Description   

The okapi instance running in the folio-preview namespace needs to be able to communicate with snapshot and released modules running in the folio-default namespace. There are at least three components to this:

1. folio-preview/okapi requires the module descriptors for each module that has been posted to folio-default/okapi.
2. folio-preview/okapi requires the deployment descriptors for each module that has been posted to folio-default/okapi.
3. folio-preview/okapi needs to be able to communicate with each module running in the folio-default namespace.



 Comments   
Comment by John Malconian [ 02/Oct/19 ]

Issue 1: The easiest way, I think, to sync the module descriptors to folio-preview/okapi with folio-default/okapi is to perform an okapi pull from folio-default/okapi prior to tenant deployment to folio-preview/okapi. This step is already part of the tenant deployment. However, we will need pull from folio-default/okapi instead of folio-registry.

Issue 2: Posting the module's deployment descriptor to folio-preview/okapi's discovery endpoint is a little trickier since there is no mechanism that sync discovery endpoints between okapis. Therefore, I think there are two ways to approach this. The first option would be to query the module's deployment descriptor at folio-default/okapi, capture the output, and post it to folio-preview/okapi prior to initializing the tenant on folio-preview/okapi. The second option would be to post the deployment descriptor to folio-preview/okapi in addition to folio-default/okapi when the module is deployed to the cluster.

Issue 3: A service definition for each module specifying an 'ExternalName' type that is used similar to CNAME aliases.

kind: Service
apiVersion: v1
metadata:
  name: service-y
  namespace: namespace-a
spec:
  type: ExternalName
  externalName: service-x.namespace-b.svc.cluster.local
  ports:
  - port: 80

I wonder also if simply modifying module's deployment descriptor on folio-preview/okapi's endpoint to include the 'fqdn' of the folio-default namespace would work also. That would be easier, but I'm not sure if it would work. Need to verify this first.

Comment by Ian Hardy [ 03/Oct/19 ]

fwiw I tried something in the Rancher UI to make sure the preview okapi could have a tenant w/a module in the default namespace enabled:

https://okapi-preview.ci.folio.org/_/proxy/tenants/previewtest/modules

It's using a service called "mod-inventory-storage-test" on the preview namespace as an alias for the service in the default namespace. On closer inspection, this looks like a Rancher feature, so may not be preferred but wanted to mention it here.

Comment by jroot [ 22/Oct/19 ]

I'm wondering if much of this work would be better served by integrating Okapi with K8s Service Discovery and etcd?

Comment by John Malconian [ 15/Nov/19 ]

Functionality has been added to the FOLIO-2011a branch of jenkins-pipeline-libs

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