marcbria
commented
3 years ago So d) looks like the most elegant solution, but this "helper script" to manage plugins is not written yet.
Clinton did his magic here: https://gist.github.com/ctgraham/d21f4153dd95928c740b533a70b3ad94#install-the-latest-version-of-all-missing-plugins
Context
OJS code is not only ojs+libpkp repositories. It's also a set of plugins evolve at different speed (and with different version numbers) than OJS.
If, for instance, you ran an ojs3 image with ojs2 plugins, your docker image will blow up. Some plugins work for 3.1 and greater, while others only for 2.x, etc.
Even right now those dependencies are managed automatically by compose (as is required by Dockerfile on image building), when your container goes to live, those plugins could be updated and unsync with the ojs version.
So, imagine you have an ojs3.2 with all the plugins updated... but you restart your container. Imagine now you use plugins that are not installed by default (need to be downloaded from the galley) or you have your own plugins.
In all those situations, when you reset your container, you will get a brand new 3.2 image with the plugins at their original state (outdated)... and you will need to update (or download) the plugins again.
(Probably this is not a huge problem in multi-tenant installations, but means a lot of work in single-tenant)
This issue is opened to think in solutions to keep plugins sync with ojs.
First solutions that raise to me are:
a) Offer a new volume to make it easy to make those plugins persistent. b) Specifically for multi-tenant: Map all your plugins volumes to same (read-only) shared path. c) Use weekly stable-snapshot images. d) Create a helper script to manage plugins (enable, disable, download, update).
a) and b) are variants of the same solution. First requires more maintenance (plugin upgrade will need to be done container by cntainer) than the second one (can upgrade all plugins from a single main-ojs), but this second solution is also risky (you need to be sure you keep your plugins and all your ojs sync).
c) would be based on mutable images and... the problems derivated form this, are explained here.
So d) looks like the most elegant solution, but this "helper script" to manage plugins is not written yet.