Versions Compared

Old Version 17

changes.mady.by.user Julian Ladisch

Saved on

compared with

New Version Current

changes.mady.by.user Julian Ladisch

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Adding configuration APIs adds interface dependencies and APIs are not consistent - need a guide for module configuration APIs


mod-configuration usage

Backend modules declaring mod-configuration usage: https://github.com/search?q=org%3Afolio-org+%22%5C%22configuration%5C%22%22+path%3A%2F%5Edescriptors%5C%2F%2F&type=code

Frontend modules declaring mod-configuration usage: https://github.com/search?q=org%3Afolio-org+%22\%22configuration\%22%22+path%3Apackage.json&type=code

Draft RFC bulletpoints

  • mod-configuration shall not be used any more due to security issues
    • module is already deprecated, no more configuration settings shall be added.
  • Distributed configuration is more native in microsyervice ecosystems and has many pros.
    • Distributed configuration shall be preferred
    • if a configuration is used by more than one module, and one module is authoritive for this configuration, then this module should hold this configuration. (Example circulation rules)
    • A consistant way getting/setting configurations should be established. API endpoints should look like /{module}/{configuration}/{entry} - Julian: Think this is not needed, maybe as a guideline, but not enforced
      • Legacy endpoints getting/setting configuration shall get deprecated
  • Centralized configuration using mod-settings can or should be used
    • by non-sensitive information, that are used by more than one module or are complete independent of any module like locale settings
    • settings that are specific to a user
  • Configurations for multiple tenants: Craig will talk to Olaminde

...

Distributed configuration means , that each module stores its configuration values itself, and offers API endpoints to query and store these values. Distributed configuration in a microservice architecture has some advantages:

  • the The modules can validate the values according to format and dependencies
  • modules Modules do not depend on a configuration module, hence a better separation of microservices can be achieved
  • since Since all API endpoints have to be documented, a basic documentation of possible configuration variables is mandatory
  • Configuration values can be cached, since no other module can change values.
  • Access to configuration values can effectively controlled by permissions defined in the module.
  • Write-only configuration values are possible, like credentials. The module can offer other operators than reading values like comparing hashes (possible in central configuration too?)
  • Modules can handle upgrade of configuration variable names or values during module upgrades more flexible

...

mod-settings solves the security problems of mod-configuration. It is the preferred module , if configuration variables shall be stored centrally. It is not recommended to develop specialized modules for other central configuration store.

...

While these configurations can also be stored in a module, the developer can decide where these values shall be stored.

Migration

For locale properties and other properties still residing exclusively in mod-configuration, the access to these properties has to be moved to the mod-settings API until the Quesnelia release. Therefore a mod-configuration module offering only READ (and DELETE?) APIs will run in Quesnelia and the modules still using mod-configuration have to transfer their properties to mod-settings or to a distributed configuration.