Add maintenance mode

[asmecher]

From SaaS document:

As a systems administrator, I would like a way to apply patches and perform software upgrades in a way that has little or no impact on the online availability of journals in the shared OJS platform.

Discussion:

@asmecher:

I think this is more of a service provider's toolset, rather than part of OJS, but we could definitely find ways to standardize and improve a toolset for the hosts within our community.

@NateWr:

One thing I can think of: a maintenance mode that would freeze database changes, so that no submissions, review comments or other actions could be taken but the reader interface is still available.

[alexxxmendonca]

I second this request.

[ajnyga]

This would be a great enhancement!

Probably metrics will have to be locked down as well during maintenance mode?

[nils-stefan-weiher]

Yes please, that would very nice for upcoming OJS 3 migrations

[JamieFowlie]

Each time I have an upgrade (managing 5 OJS installations fo various journals), I get nervous and come looking for a solution to upgrading without knowing if people are currently doing serious work in the backend. At some point I need to change the config file installed to off to get the 2 minutes I need to do the upgrade and swap out the files. I prefer not to change document folder names, so I would love a maintenance mode that would lock out editors and managers for these brief minutes of downtime.

[NateWr]

@JamieFowlie raises a good point that there are maybe two parts to this, one easier than the other:

1. Kick out editors/authors/reviewers from the backend and stop work from happening that effects the database (including writing to sessions or usage stats tables).

2. Keep the reader-fracing frontend up and running so that there is no visible downtime for published material.

Doing the second will be really difficult because we rely on the sessions table and don't have a clear distinction between "frontend" and "backend" pages.

But I think that we could do something like the first without too much difficulty, by hooking into LoadHandler, checking if someone is an admin and, if not, returning a maintenance mode screen.

@mfelczak I know that this is one the hosting team has been interested in. Would it help to do the first even if we can't do the second?

[diegoabadan]

including writing to sessions or usage stats tables

The statistics table is a point that is usually quite expensive in upgrades of major OJS installations.

Separating it, perhaps as a micro service, would not bring advantages, in addition to facilitating the implementation of item 2?

And for sessions, the option of being able to store them in something like Redis could be interesting.

[diegoabadan]

Forum post related to this issue:
https://forum.pkp.sfu.ca/t/read-only-mode-on-ojs-ops-omp/61001

[mfelczak]

@mfelczak I know that this is one the hosting team has been interested in. Would it help to do the first even if we can't do the second?

@NateWr, confirming that this would be helpful as the first step before a production install is taken offline to start an upgrade.

[NateWr]

The statistics table is a point that is usually quite expensive in upgrades of major OJS installations.

This should improve from 3.3 onwards because we have replaced our database migrations toolset. We expect downtime during upgrades to be significantly shorter.

[felixhelix]

I second the request for a maintenance mode. Preferably one that leaves journals available but prevents changes in the database.

[diegoabadan]

It might be interesting to see how gitlab manages to upgrade without downtime:
https://docs.gitlab.com/ce/update/index.html#upgrading-without-downtime

Maybe it's applicable to OJS.

[asmecher]

Interesting, @diegoabadan -- though that's more related to how we write migrations than adding a maintenance mode. I'll consider some of these approaches in coding upgrade scripts in the future.

[diegoabadan]

You're right, I was thinking more about how to avoid needing a maintenance mode. :)

Thank you and cheering for an increasingly painless upgrade process.

[louisaoc]

I vote for the original request of having a maintenance mode (I don't mind blocking viewers from published content as well since it's easier to achieve). Maintenance mode covers other use cases over and above an upgrade.

• Actual maintenance that's not an upgrade
• Migrating to another hosting provider, so the current prod must just show in maintenance while the migration takes place and services are re-directed

[henriqueramos]

During my free time, I've created a small plugin to enable maintenance mode. In a spirit like Magento and his .maintenance.flag file.

https://github.com/henriqueramos/maintenanceMode/releases/tag/3.3.x

This is a release for 3.3.x version (probably works well on the previous versions too).

Any comments and PRs are welcome.