[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: |
|
||||||||||||||||||||||||||||
| 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:
We have also talked about a possiblity of a special
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:
|
| 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: 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. |
| Comment by Adam Dickmeiss [ 10/Feb/17 ] |
|
The environment (system-wide properties) are passed during module deployment. See
|
| Comment by Jakub Skoczen [ 10/Feb/17 ] |
|
During the call today we have discussed and agreed that:
Additionally, we want to confirm that this new way of configuration works well in the CI/demo provisioning:
|
| Comment by Jakub Skoczen [ 10/Feb/17 ] |
|
Re-open to keep around untill related/blockers are fixed. |