Details
-
New Feature
-
Status: Open (View Workflow)
-
P3
-
Resolution: Unresolved
-
None
-
None
-
-
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).