Foreman-db-manage-rake usage?

Hi all,

I’m having an issue with understanding the usage of the foreman-db-manage-rake parameter on the foreman-installer

I know there are currently several issues open due to the fact that when doing an upgrade with Foreman, the RPM based installers will run (re-run) the db rake seed and migrate jobs for each and every plugin. In our environment this translates to around 45-60 minutes as it reruns like 10 times.

Now - i have many foreman servers, all identically configured in terms of roles, features, and plugins, and all tied to the same single database for puppet scalability. When i upgrade i also need to repeat this process on each one which can take a while as the db seed and migrate runs repeat on each one.

I “think” that i can leave one node with foreman-db-manage-rake set to TRUE to ensure all the rake DB upgrade stuff is done as expected, and then set it to FALSE on the remaining nodes, which “should” skip the db rake stuff on them, as its already been done and not needed again. Does this sound correct?

Thanks for anyone who can help, I’ve checked these forums as well as googled this specific switch and haven’t found anything more descriptive than the single line description on the foreman manual page. Want to be sure I’m fully understanding what it does (and any potential ramifications) before i go flip it in my answer file(s) prior to upgrading to 1.15.6

~Jason Lang

Yes. See and for the actual implementation details.

1 Like

Thanks mmoll,

I was able to set this, but unfortunately it didn’t seem to work.

I suspect that since i’m upgrading via the RPM’s directly, they don’t honor the parameters within the answer file that foreman-installer does. I could see the seed(s) rake tasks running via ps-ef, but it looks like the RPM postinstall tasks on upgrade don’t call foreman-installer directly, but rather run several tasks directly themselves.

Wondering if i should submit this as a feature request (RPM installers honor foreman-answer parameters) or if this is expected behavior due to RPM limitations.

Unfortunately that’s correct, we’ve talked about moving db:migrate and db:seed out of the RPM %posttrans before, It would be awesome if you could send a PR changing that behavior.