[FOLIO-437] Standardize module deployment options/config Created: 12/Jan/17  Updated: 12/Nov/18  Resolved: 16/Feb/17

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

Type: Umbrella Priority: P3
Reporter: Jakub Skoczen Assignee: Jakub Skoczen
Resolution: Done Votes: 0
Labels: sprint6, sprint7, sprint8
Remaining Estimate: Not Specified
Time Spent: 1 hour
Original estimate: Not Specified

Issue links:
Blocks
is blocked by OKAPI-232 Initialize modules Closed
is blocked by FOLIO-465 Align CI and demo/bb with envar based... Closed
Relates
relates to METADATA-43 Move metadata modules to standardised... Closed
relates to OKAPI-240 module deployment properties Closed
relates to METADATA-22 Create deployable Module Descriptor f... Closed
Sprint:

 Description   

Currently we provide certain things (like e.g database connection info, okapi url, etc) in a module implementation specific way. We need to standardize on methods supported across the platform. Some options include:

  • env vars
  • command-line switches
  • config file (e.g JSON) supplied to STDIN

We have also talked about a possiblity of a special

  • init web service

invoked by okapi after module startup. But certain things like DB conn info or Okapi URL may be required before the module is able to handle requests so this is a less appealing option.



 Comments   
Comment by Heikki Levanto [ 12/Jan/17 ]

As it is now, Okapi passes the Okapi URL to the modules in every request, in a special header. Of course that comes in too late for the module startup code to make any request, which it is likely to need to read its configuration. I suggest we add this to the command line too.

Okapi itself is not setting up any environment variables for the modules, at the moment. Of course it could do that. But those may be tricky with Docker containers etc. I like the command like options better.

Most of the config should be kept in the database, where the module will fetch it when it needs it. But the database address is a special case, the module needs to know it before connecting to the database. Today we discussed some alternative approaches:

  • Let Okapi maintain a small amount of config data for each module, and provide it via headers or via a dedicated API.
  • If we want to pin different tenants to different databases, this database address needs to be provided to each request separately, as new tenants can come into being after the module has been started up. So far we tend to lean towards not supporting this kind of separation directly. There are some workarounds, like runninng different instances of the modules with different database parameters, or even different Okapi installations for such rare cases.
  • At the moment a command line parameter may be the easiest way to go
Comment by Adam Dickmeiss [ 19/Jan/17 ]

The command line is probably the best option. Environment variables are process-wide and they could be a problem for a process like Okapi . File storage is problematic on its own with containers and such.

I think this boils down to:
1. add a key-value storage to Okapi (hazelcast shared data).. Obviously something needs to manage that. Perhaps a file for Okapi to read at start up wil suffice for now.
2. pass those key-values in deployment.

For Okapi URL – which is not shared – we can add a new key %u in deployment - or put it in same args as key-values from 1. We could make a special %jopt that expands to -Dkey1=value1 -Dkey2=value2 etc.. in process invocation.. calling it dopt because it's this Java property liike command line optios.. But it should be easy to parse in all languages that can read properties.. We can always make another type of option passing if necessary.

Comment by shale99 [ 19/Jan/17 ]

i think we need to maybe think about , for example , db access.
okapi may push this out to modules via command line - but there will be a hierarchy to this i believe.
we may want to pass the connection, but also a limit on the amount of connections, etc... to protect the db for example. so it would be data and how to use that data

Comment by Adam Dickmeiss [ 10/Feb/17 ]

The environment (system-wide properties) are passed during module deployment. See OKAPI-240 Closed .

Comment by Jakub Skoczen [ 10/Feb/17 ]

During the call today we have discussed and agreed that:

  • envar handling is ready both in Okapi and RMB
  • any module depending on RMB >= 6 handles envvars automatically
  • Marc will go ahead and test if the above is true with the metadata modules ( METADATA-43 Closed )

Additionally, we want to confirm that this new way of configuration works well in the CI/demo provisioning: FOLIO-465 Closed

Comment by Jakub Skoczen [ 10/Feb/17 ]

Re-open to keep around untill related/blockers are fixed.

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