Project

General

Profile

Feature #30862

Tracker #29939: Improve setting definition DSL and move setting registry to memory

Introduce SettingRegistry as a setting inventory

Added by Ondřej Ezr about 1 year ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Settings
Target version:
-
Difficulty:
Triaged:
Yes
Bugzilla link:

Description

Bring int SettingRegistry, that should be an inventory for the settings.


Related issues

Related to foreman-tasks - Bug #32729: Dynflow doesn't reflect changes in SettingClosed
Related to Foreman - Bug #32953: Fix the creation of missing settingsClosed
Related to Foreman - Bug #32963: Load only core setting values the first time we load themClosed
Related to Foreman - Refactor #33280: Mark Settings defined by DSL as special category in DBClosed
Blocked by Foreman - Refactor #30860: Create SettingPresenter as a proxy for setting UI valuesClosed

Associated revisions

Revision 8137b14c (diff)
Added by Ondřej Ezr 5 months ago

Fixes #30862 - introduce SettingRegistry (#8002)

SettingRegistry keeps all the setting information as set of SettingPresenters in memory.
This registry should be the public API for accessing setting values and keeps all the information about settings.
That will allow dropping all information except `name` and `value` from database.

The public interface should be:
`Foreman.settings[<name>] => value` with syntactic suggar `Setting[<name>]` proxying to this method.

We load values from database per request and repopulate the values, what is quite fast. This allows us dropping the cache for setting.

Key implementation features:
  • Initialize the registry manually at specific moment and note if the registry is
    ready or not by `ready?` method.
  • Reload values by `Foreman.setting.load_values` before every request
  • Disables validations on Setting default values creation as those come from code and thus should be always valid, also this creation will be dropped in the future

Revision 74da3011 (diff)
Added by Ondřej Ezr 5 months ago

Refs #30862 - do not validate new settings

While creating the settings, the definitions are not loaded yet, so the
validations depending on other setting values are failing. We should not
validate on create anyway.

This is fixing a forgotten validation on new setting from 8137b14c.

History

#1 Updated by Ondřej Ezr about 1 year ago

  • Blocked by Refactor #30860: Create SettingPresenter as a proxy for setting UI values added

#2 Updated by The Foreman Bot about 1 year ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/8002 added

#3 Updated by The Foreman Bot 5 months ago

  • Fixed in Releases 2.5.0 added

#4 Updated by Ondřej Ezr 5 months ago

  • Status changed from Ready For Testing to Closed

#5 Updated by The Foreman Bot 5 months ago

  • Pull request https://github.com/theforeman/foreman/pull/8464 added

#6 Updated by Ondřej Ezr 3 months ago

  • Related to Bug #32729: Dynflow doesn't reflect changes in Setting added

#7 Updated by Ondřej Ezr 2 months ago

  • Related to Bug #32953: Fix the creation of missing settings added

#8 Updated by Ondřej Ezr 2 months ago

  • Related to Bug #32963: Load only core setting values the first time we load them added

#9 Updated by Ondřej Ezr about 1 month ago

  • Related to Refactor #33280: Mark Settings defined by DSL as special category in DB added

Also available in: Atom PDF