[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: |
|
||||||||
| 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. |
| 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 |