DR-000039 - Distributed vs. centralized configuration
Submitted Date | Jul 3, 2024 |
Approved Date | Aug 5, 2024 |
Status | ACCEPTED - IN UPDATE REVIEW |
Impact | MEDIUM |
Overrides/Supersedes
-
RFC
Stakeholders
Developers
Contributors
@Florian Gleixner
@Julian Ladisch
Approvers
TC approved
Background/Context
Give developers a guide how to implement module configuration.
Assumptions
Folio is a microservice platform
Constraints
-
Rationale
Done through the RFC process
Decision
Drop mod-configuration module. Favour distributed configuration over centralized configuration, provide guidelines for storage of configuration values.
Decision Update
Development teams are not able to complete the changes described in the RFC https://github.com/folio-org/rfcs/blob/master/text/0006-folio-distributed-vs-centralized-configration.md in the Sunflower release. Therefore the “Timing” Section from the RFC is no more valid, and the timing will be the following:
Timing (changes in italic)
Since most modules already store configuration values in a distributed way, only some cases need to be addressed.
For locale properties and other properties still residing exclusively in mod-configuration, the access to these properties has to be moved to the module (distributed configuration, preferred) or to the mod-settings (centralized configuration, not preferred) after the Trillium release. Therefore a mod-configuration module offering only READ and DELETE APIs will run in Umbrellaleaf and the modules still using mod-configuration have to transfer their properties to mod-settings or to a distributed configuration. Migrated configurations in mod-configuration have to be deleted. This has to be done during module upgrades.
mod-configuration will be removed in the release following the Umbrellaleaf release.
Implications
See RFC
Other Related Resources