[FOLIO-3171] folio-ansible: environment variables dont make it to docker Created: 21/May/21  Updated: 16/Jul/21  Resolved: 16/Jul/21

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

Type: Bug Priority: TBD
Reporter: Florian Gleixner Assignee: Wayne Schneider
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint: DevOps Sprint 116, DevOps Sprint 115, DevOps Sprint 117, DevOps Sprint 118
Development Team: FOLIO DevOps
Release: R1 2021

 Description   

Overview:
Steps to Reproduce:

  1. Try to install folio using folio-ansible

Expected Results:
Actual Results:

Ansible Playbook error:

TASK [okapi-tenant-deploy : Post install list for deployment and enabling] ********************************************************************************************************************************************************************
fatal: [XXX.XXX.XXX.XXX]: FAILED! => {"changed": false, "connection": "close", "content": "Deployment failed for service mod-search-1.3.0. Could not connect to 192.168.128.89:9194: finishConnect(..) failed: Connection refused: /192.168.128.89:9194", "content_length": "156", "content_type": "text/plain", "elapsed": 822, "msg": "Status code was 400 and not [200]: HTTP Error 400: Bad Request", "redirected": false, "status": 400, "url": "http://192.168.128.89:9130/_/proxy/tenant
s/bvb/install?deploy=true&tenantParameters=loadReference%3Dtrue%2CloadSample%3Dtrue", "vary": "origin"}

 

Looking at the okapi log, i see:

2021-05-21T20:27:08,505 INFO  DockerModuleHandle   mod-search-1.3.0 20:27:08.500 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
2021-05-21T20:27:08,505 INFO  DockerModuleHandle   mod-search-1.3.0 org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'folioEnvironment' defined in file [/opt/folio/BOOT-INF/classes/org/folio/search/con
figuration/properties/FolioEnvironment.class]: Unexpected exception during bean creation; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'okapi.url' in value "$

{okapi.url}

"

 

So mod-search cannot run. With docker inspect i can see the environment:

           "Env": [
               "DB_MAXPOOLSIZE=5",
               "DB_CHARSET=UTF-8",
               "DB_PORT=5432",
               "ELASTICSEARCH_USERNAME=elastic",
               "SYSTEM_USER_PASSWORD=Mod-search-1-0-0",
               "DB_HOST=192.168.128.89",
               "DB_QUERYTIMEOUT=60000",
               "KAFKA_PORT=9092",
               "ELASTICSEARCH_PASSWORD=s3cret",
               "INITIAL_LANGUAGES=eng",
               "KAFKA_HOST=192.168.128.89",
               "ELASTICSEARCH_HOST=192.168.128.89",
               "DB_USERNAME=folio_admin",
               "ELASTICSEARCH_URL=http://elasticsearch:9200",
               "JAVA_OPTIONS=-XX:MaxRAMPercentage=66.0",
               "ELASTICSEARCH_PORT=9301",
               "DB_DATABASE=okapi_modules",
               "DB_PASSWORD=folio_admin",
               "PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
               "LANG=en_US.UTF-8",
               "LANGUAGE=en_US:en",
               "LC_ALL=en_US.UTF-8",
               "JAVA_VERSION=jdk-11.0.10+9",
               "JAVA_HOME=/opt/java/openjdk",
               "JAVA_APP_DIR=/opt/folio"

 

which is missing the OKAPI_URL Environment.

Meanwhile checking the Ansible Output, i see:

TASK [okapi-tenant-deploy : Build install list for modules with deployment] *******************************************************************************************************************************************************************

....

ok: [138.246.234.10] => (item={'name': 'mod-search', 'version': '1.3.0', 'deploy': True, 'docker_env': [{'name': 'ELASTICSEARCH_URL', 'value': 'http://192.168.128.89:9301'}, {'name': 'OKAPI_URL', 'value': 'http://192.168.128.89:9130'}, {'n
ame': 'JAVA_OPTIONS', 'value': '-XX:MaxRAMPercentage=66.0'}]})  

 

Where OKAPI_URL and ELASTICSEARCH_URL are correctly set. The same happens to other modules with special environment like mod-pubsub.

I did not yet find the point where the environment gets lost.

Happens on folio-ansible main and r1-2021-release, does not happen on q3-2020-release
 i think.

Additional Information:
URL:
Interested parties:



 Comments   
Comment by Wayne Schneider [ 15/Jul/21 ]

Florian Gleixner sorry for the delay in getting to this issue.

My notes here assume that you are using Okapi to deploy modules on a host using the Docker daemon. Obviously, if you are deploying modules using some other mechanism, you will need to control the module environment using those tools.

Okapi provides environment variables to modules it deploys in three ways, I believe in this order (i.e. the first one wins):

  1. Environment variables provided as part of the descriptor property of a deployment descriptor – specific to one module, posted to /_/discovery/modules
  2. System-level environment variables – provided to all modules, posted to /_/env
  3. Default values provided as part of the launchDescriptor property of a module descriptor – specific to one modules posted to /_/proxy/modules or pulled in from an upstream module descriptor repository

folio-ansible supports all three of these with different roles in different ways. I think the problem you are running into has to do with some very confusing roles in folio-ansible that are tricky to try to keep straight. Sorry about that, I probably wrote the code several years ago, and I find it tricky to keep straight

  1. Deployment descriptor: use the okapi-deployment role. This will parse the folio_modules variable (created with the build-module-list role) to generate and post deployment descriptors for the modules, which will cause Okapi to deployment with the specified environment. This is the strategy used in CI for "snapshot" builds. You need to call in order the roles build-module-list, okapi-deployment, and okapi-tenant-deploy
  2. Okapi system-level environment: set the Ansible variable module_env. It will be picked up by either the okapi-deployment role if you are using it, or by the okapi-tenant-deploy role. If you are using okapi-deployment you must set module_env to [] when you invoke okapi-tenant-deploy or it will attempt to reset the Okapi environment and fail. This approach is used in all the CI builds for database connection defaults, obviously you would not want to do that outside of a development environment.
  3. Defaults in the module descriptor: for this approach, do not pull module descriptors using the okapi-pull role. Instead, register each module descriptor separately, overwriting the default values with your own new defaults, using the okapi-register-modules role. This is the strategy used in CI for "testing" and "release" builds. You need to call in order the roles build-module-list, okapi-register-modules, and okapi-tenant-deploy

Some models for using these roles can be found in the folio.yml file in folio-ansible (used by CI in combination with the files in group_vars to build Vagrant boxes).

I hope that helps! I do not think there is actually a bug here, just some confusing code that lacks documentation.

Comment by Florian Gleixner [ 16/Jul/21 ]

Hi Wayne,

thank you for explanations. I was able to install folio with folio-ansible at 7.june, and with your explanations, i think the commit

https://github.com/folio-org/folio-ansible/commit/98180e5b3dbccba60e1e81a0ae04a3299ad1317e

fixed my issue.

Folio-ansible could be a great alternative for the single server installation method. We should describe it better in the documentation.

Thank you!

 

Florian

Comment by Wayne Schneider [ 16/Jul/21 ]

Great, I'm glad I accidentally fixed your issue in early June – so there was a bug!

The single-server installation documentation was originally built by reverse engineering the folio.yml playbook in folio-ansible. Unfortunately, the project does not currently have the DevOps resources available to maintain it very well.

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