When should the Installer restart Puma

Ohai,

today, in production deployments, to reload the app (e.g. because the code changed), one needs to restart the foreman.service, which hosts our Puma service.

This is done by the installer in roughly to places:

To translate this from Puppet to English:

  • if the installer performed any basic install steps (like installing core packages) it will restart Puma
  • if the installer changed anything in the configuration it will restart Puma
  • if the installer did any database changes (like running migrations) it will restart Puma
  • if the installer installed a plugin it will restart Puma

While this sounds solid on the first look, one can construct cases where Puma is not restarted:

  • a core package is updated via the package manager, but has no new migrations (this is luckily handled by packaging, tho)
  • a plugin is updated via the package manager, but has no new migrations
  • a plugin is installed via the package manager, but has no (new) migrations

The last one is not that bad, as the worst case is that the new plugin is not loaded at all and doesn’t do any harm.

But the other (I ignore core, as that is handled by packaging) is a bit more involved. It results in on-disk and in-memory code being not in sync, and probably resulting in the user thinking a fix was applied, while it really was not. Another problem is that Ruby installs its gems in versioned folders (like katello-4.2.0), so when we update (e.g. to katello-4.2.1) and don’t restart Puma Rails could try to read templates (or other files) from disk in the 4.2.0 folder, which doesn’t exist anymore.

Thus, I think, we should see how we can restart Puma more often. At the same time, restarting it after every plugin installation/upgrade can result in way too many restarts when performing actions on multiple plugins (like when upgrading from one Foreman version to another).

So, thoughts and ideas welcome how to fix this :slight_smile:

1 Like