[FOLIO-513] Consider to package/expose ModuleDescriptor within/from module itself Created: 22/Mar/17  Updated: 15/Jul/20

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

Type: New Feature Priority: P3
Reporter: Hongwei Ji Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 2 hours, 30 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-487 use ModuleDescriptors provided in the... Closed
relates to FOLIO-508 Associate and Include ModuleDescripto... Closed
Sprint:
Development Team: Core: Platform

 Description   

This purpose of this ticket is to document some thoughts exchanged on slack channel during March 21-22, 2017.

Depends on how we view the relationship between module and Okapi, we can say that a module is strictly a part of OKAPI and should be viewed through Okapi, or it is a relatively “separate and standalone” entity (microservice?) that can be plugged into OKAPI. Following thinking is mostly from the latter perspective.

Currently, module descriptor is not packaged inside module artifact (jar or Docker) itself. It has to be located separately from GitHub project at different root/sub folder depends on the project. It would be nice to have module descriptor packaged inside the module itself.

For a running module that is not fully deployed/managed by OKAPI, it would be beneficial to have module descriptor exposed from the module itself at run time, so the module can be identified without the help of OKAPI. For example, RMB modules have /admin/health API, there could be a /admin/md as well. For a short term work around, the md.json can be copied to /ramls folder to leverage RMB /apidoc API to expose module descriptor.

An extension to above, if a module has its built-in exposed module descriptor, theoretically the current Okapi register and discovery steps can be combined to one. A single /_/discovery call (with instId and url info) triggers okapi to pull the md from module itself to do both register and discovery (semi-auto discovery).



 Comments   
Comment by Heikki Levanto [ 23/Mar/17 ]

The use case for this is an installation where services are deployed by some outside agent, not Okapi. In such an installation, it seems clumsy to maintain running services, and related ModuleDescriptors.

We already allow a POST to Okapi's discovery with a moduleId, and a URL where it is to be found. But that moduleId has to refer to a ModuleDescriptor already known by Okapi. It would not be too difficult to allow also a POST to the discovery, with one URL for the running service, and another where Okapi would fetch the moduleDescriptor. These could well be different endpoints in the same service, or the latter couild refer to a central reprository of some sort.

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