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 about 1 year ago. Updated 3 months ago.

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

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 10 months 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 10 months 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.

Revision bcfa6ade (diff)
Added by Adam Ruzicka 3 months ago

Refs #34305 - Fix load_values test

History

#1 Updated by The Foreman Bot about 1 year 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 about 1 year ago

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

#3 Updated by Ian Ballou 11 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 11 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 10 months ago

  • Target version set to 3.4.0

#6 Updated by The Foreman Bot 10 months ago

  • Fixed in Releases 3.4.0 added

#7 Updated by Ondřej Ezr 10 months ago

  • Status changed from Ready For Testing to Closed

#8 Updated by Evgeni Golov 10 months ago

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

#9 Updated by The Foreman Bot 10 months ago

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

#10 Updated by The Foreman Bot 3 months ago

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

Also available in: Atom PDF