Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to keep ojs plugins sync with ojs? #37

Open
marcbria opened this issue May 14, 2021 · 2 comments
Open

How to keep ojs plugins sync with ojs? #37

marcbria opened this issue May 14, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@marcbria
Copy link
Collaborator

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.

@marcbria
Copy link
Collaborator Author

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

@marcbria
Copy link
Collaborator Author

marcbria commented Jan 14, 2022

Henrique xmas present that will probably grow to offer plugins support:
https://github.com/henriqueramos/scout

@marcbria marcbria added the enhancement New feature or request label Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant