Project

General

Profile

Refactor #34305

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

Stop creating settings in the DB

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

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

Description

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


Related issues

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

Associated revisions

Revision de56ffb2 (diff)
Added by Ondřej Ezr about 1 month ago

Fixes #34305 - stop creating settings in DB (#9050)

With the setting DSL, we hold all the necessary values for settings in the memory.
We can now stop creating records for the settings in the database.

Revision 9ae59fa1 (diff)
Added by Ondřej Ezr about 1 month ago

Refs #34305 - forgotten category for new settings

We have accidently removed category for new records, but we have left
the category wiring, so we need to keep it for now.

History

#1 Updated by The Foreman Bot 5 months ago

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

#2 Updated by Adam Ruzicka 4 months ago

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

#3 Updated by Ian Ballou about 2 months 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.

#4 Updated by Ondřej Ezr about 2 months 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)

#5 Updated by Amit Upadhye about 1 month ago

  • Target version set to 3.4.0

#6 Updated by The Foreman Bot about 1 month ago

  • Fixed in Releases 3.4.0 added

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

  • Status changed from Ready For Testing to Closed

#8 Updated by Evgeni Golov about 1 month ago

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

#9 Updated by The Foreman Bot about 1 month ago

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

Also available in: Atom PDF