Mechanism to give curators plenty of warning before scheduled downtime

[jar398]

If there is scheduled downtime at, say, 4pm, then we would like to give curators plenty of advance notice, like at least a few hours, so they will know about the downtime when they start their curation session, and can plan accordingly.

Solution 1. We could use email to tell them. Problem a: it's unlikely that all active curators are on the google group. We could add a message to the curator app - maybe on every login - to tell them to subscribe to the group to get downtime and other notices. Then, if they don't subscribe and their session is cut short by downtime, we can say it's their own fault. Problem b: these messages are spam for people on the group who are not doing curation.

Solution 2. Improve the current 'maintenance_notice' feature. Currently the notice is coupled to logic that disabled study creation and editing, because it is meant to be used during an outage, not in advance of an outage. If we could put up the notice without disabled study creation/editing, then we could put up the notice hours or days in advance.

(difficulty around "starting a curation session": maybe some users keep one session running for days or weeks? think about what happens in this case)

Useability nit: I find the current procedure of editing the config file and restarting apache to be a bit awkward. This operation will probably happen every week and the person doing it (e.g. me) will need to remember how to do it and will want it to be easy (e.g. with a single shell command on one's own computer, no requirement to ssh over and edit a file). Restarting apache also makes me nervous, both because it creates its own downtime and because it is a vunerability (system might break at that point), so if there's a way to avoid that it would be nice.

• Also I think the notice shouldn't get overwritten by re-deploying the webapp, as it is now; it would be nice if we could test the deployment, and only after that point, cancel the notice.

So ideally:

• I'm at my laptop
• I prepare a notice and put it in a local file
• I run a script, which copies the notice and (if necessary) pokes apache/web2py
• wait
• do maintenance
• I run a second script (or the same one), which cancels the notice (or replaces it with another)

[mtholder]

It seems to me is the simplest thing that should work is:

1. have the curator app's controllers look in their opentree/curator/private dir for a "warn-impending-maintenance.txt" file and a "undergoing-maintenance" file.
2. if the first is found, a message is displayed in the header and curation is allowed. If the second is found curation is disabled.

Then you can just scp the file to start maintenance, move it to go into maintenance mode, and remove it to leave maintenance mode. We only have 1 or 2 editing controllers in the curation app, so I'm not sure we need to get fancy with this.

[jimallman]

We only have 1 or 2 editing controllers in the curation app, so I'm not sure we need to get fancy with this.

There's an existing get_maintenance_info method called by all controllers, so we can just change the behavior here and the outcome in the main page template.

[jar398]

I think the announcement feature could just as usefully by used for announcements in general, e.g. noting a new synthetic tree (with hyperlink to longer announcement) or UI feature. If I'm right then calling it xxx_maintenance_xxx is probably not appropriate.​

[jimallman]

I think the announcement feature could just as usefully by used for announcements in general

Agreed. Perhaps this file could be called "header-announcement.md" to allow basic text styles and links. This message would appear in the header, but would not affect behavior or block curation activity.

We'll presumably want some kind of session variable to remember if someone closes/dismisses this message, or it will keep re-appearing on each new page.

[jimallman]

On further reflection, we might want to use unique (date-specific?) filenames for these announcements:

• header-announcement-2016-10-12.md
• header-announcement-2016-10-16.md
• header-announcement-2016-10-16-fixed.md
• header-announcement-anything-else.md

This way a session variable could be something like 'announcementClosed': 'header-announcement-2016-10-12'. This would ensure that they see any new announcement at least once, then (once it's been dismissed) they won't be bothered for the rest of the current session.

[jar398]

Here's what NCBI does, for reference: