2025-11-05 Environment Variable Management III

2025-11-05 Environment Variable Management III

Date

Nov 5, 2025 

 https://zoom.us/j/935492890  

Attendees 

  • @Wayne Schneider

  • @Olamide Kolawole

  • @Maccabee Levine

  • @Julian Ladisch

  • @Kevin Day

  • @Matt Weaver

  • @Craig McNally

  • @Shelley Doljack

  • @Jenn Colt

  • @Ingolf Kuss

Time

Item

Who

Notes

Time

Item

Who

Notes

1 min

Scribe

 

@Ingolf Kuss is next, followed by @Julian Ladisch

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

 

Module Evaluation Criteria

ALL

Proposed Additional Module Evaluation Criteria:

  • [ ] FOLIO declared environment variables follow the naming convention [Link to Env Var Document]

  • [ ] ModuleDescriptor includes description for each variable

  • [ ] Required vs optional variables clearly marked in the ModuleDescriptor

  • [ ] Module startup validates required variables and fails fast with clear errors **get log from developers

 

Review Environment Variables

ALL

Wayne: ENV is on the top level and is already there. It is in the module descriptor and the launch descriptor. It can be used to generate documentation. It would not be a breaking change in the documentation. It lives in Okapi. So there is a set of environment variables in the launch descriptor that everyone can look at.

Craig: In Eureka, the module descriptor is treated as an object in the application descriptor. So, it is the same as in Okapi.

Makes sense to use OpenAPI instead of RAML.

Decision: We will use the top level .env of the module descriptor for documentation. We need to create a Jira issue for this.

Olamide: What if the default value in the module descriptor is out of sync with the value in the code ?

Wayne: That will happen, it will be unavoidable. That will be a bug.

Matt: Not everyone uses Kubernetes and Helm Charts.

Ingolf / Shelley: How do the default values of the launch descriptors come into the Helm Charts' default values ?

The team that builds the Helm charts can make use of the default values.


The description field should be populated.

 

Required vs. Optional variables

reporting error messages. Should a link to the documentation be provided ?

For Required Values:

Matt: The details don’t matter. Important is a clear error message. I must fail fast on startup, so the error gets noticed immediately, and not days later.

One could put some checks in the docker build script. The docker file is part of the project.

Kevin: Build some script into the container, that does these checks and fails fast. This does not affect the code.

Optional Values:

Matt: there may not be a way to do this without redundant code . At least with Spring Boot.

Craig: What about the sidecars ? There is no module descriptor for them. How do we document that ?

NA

Zoom Chat

 

Heute

Wayne Schneider an Alle 17:14
https://s3.amazonaws.com/foliodocs/api/okapi/p/okapi.html

Matt Weaver an Alle 17:47
Checking for required env vars in the entry point script would be awesome! Good way to avoid things slipping through the cracks

Matt Weaver 17:54 (Bearbeitet)
To be clear: I’m all for logging at least some optional env vars :) Some of them are very useful to log. I just don’t want to log all of them