Refactor #32255
openDrop db_pending_seed setting
Description
Summarizing the discussion from IRC and writing it down for others to see. The relevant part is here:
What essentially happens is that the setting is read (via foreman-rake config) and if it isn't false (true or nil), a seed is triggered. If we have a different way to know if we need to run a seed, then we can drop it. We need that to determine idempotency. We also can't drop seeding since there are installer parameters to seed initial data. With db:migrate we solved it here:
https://github.com/theforeman/puppet-foreman/blob/67f78b9b45d1b5b8118b6575bf1902056d1978d0/manifests/database.pp#L29
That rake task is provided by Rails. Out of the box there is no such thing for seeding, but we do have logic in our project to determine it. If it can be properly exposed via some script (like a rake task, db:abort_if_pending_seed) then it should be easy to drop the setting.
Note that the installer can't simply always run seed. If it runs the exec, it will trigger a refresh which can cause service restarts. This would slow down the installer and can lead to downtime of services.
Updated by Ewoud Kohl van Wijngaarden almost 4 years ago
- Related to Refactor #32242: Drop db_pending_migration setting added