Project

General

Profile

Actions

Refactor #34305

closed

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

Stop creating settings in the DB

Added by Ondřej Ezr about 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Settings
Target version:
Fixed in Releases:
Found in Releases:

Description

We are still creating all the setting information in the settings table, but that can be dropped as of now.


Related issues 2 (1 open1 closed)

Related to Foreman Remote Execution - Bug #34645: Some migrations will break after settings won't be stored in DBNewAdam RuzickaActions
Related to Foreman - Bug #34994: "ERROR: relation "application_records" does not exist" when using models inside migrationsClosedEvgeni GolovActions
Actions #1

Updated by The Foreman Bot about 2 years ago

  • Status changed from New to Ready For Testing
  • Assignee set to Ondřej Ezr
  • Pull request https://github.com/theforeman/foreman/pull/9050 added
Actions #2

Updated by Adam Ruzicka about 2 years ago

  • Related to Bug #34645: Some migrations will break after settings won't be stored in DB added
Actions #3

Updated by Ian Ballou almost 2 years ago

Hello,

What Foreman version is this expected to make it into? Since Katello will need to change as well, it would be best to sync-up.

Actions #4

Updated by Ondřej Ezr almost 2 years ago

Hi Ian!

I'd like to align it with 3.4 exactly for that reason, tho Katello should be quite ready as I've sent some PRs Katello way already, but obviously we will not know what breaks prior merge, there might be dragons and some are already. I've send some info Jeremy's way, but let's have it here:

Following text is sligly redacted for wide audience :)

Hi, there is an issue in katello with PR ^^
It happened to foreman as well and it was fixed in https://github.com/theforeman/foreman/pull/9155
so the root cause is that some weird AR subclass is initialized before some well behaved class (the well behaved first class was always Setting, but it will no longer be true)

Q: what do we need to do to fix it?

A:
What I did in Foreman was to put `pp caller` on top of <foreman>/app/models/application_record.rb, figured that first time it gets required is from Facet, so I've postponed facet registration and all worked well again

so my educated guess would be you will need to move https://github.com/Katello/katello/blob/2a10b1eb15f0dab79630aeba832b67b8ef043767/lib/katello/plugin.rb#L291 into a [in_to_prepare](https://github.com/theforeman/foreman/blob/8e0e3f78fb69789cacc29888bc121a541134269c/app/registries/foreman/plugin.rb#L481)

Actions #5

Updated by Amit Upadhye almost 2 years ago

  • Target version set to 3.4.0
Actions #6

Updated by The Foreman Bot almost 2 years ago

  • Fixed in Releases 3.4.0 added
Actions #7

Updated by Ondřej Ezr almost 2 years ago

  • Status changed from Ready For Testing to Closed
Actions #8

Updated by Evgeni Golov almost 2 years ago

  • Related to Bug #34994: "ERROR: relation "application_records" does not exist" when using models inside migrations added
Actions #9

Updated by The Foreman Bot almost 2 years ago

  • Pull request https://github.com/theforeman/foreman/pull/9246 added
Actions #10

Updated by The Foreman Bot over 1 year ago

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

Also available in: Atom PDF