Maintenace page

[lorenzo-cavazzi]

Motivation

We are planning to do regular updates on GitLab (~1/month, expected duration <30min each) during which renkulab won't be usable. The first one will probably happen on 15.04.2020 and will last longer (a few hours).
We may want to put a maintenance page during that time.

Proposal

A simple solution would be creating the page and set it on/off through a variable in /helm-chart/renku-ui/values.yaml that we read in src/index.js. Renku team members would be able to easily change that value to turn on/off the page.

A more complex solution would use an array of maintenances with a start and a end timestamp. The UI can show the maintenance page during these hours, as well as a warning message in the Landing page for a while (2 days?) before the event.

We could instead get the maintenance information from a backend API, maybe the same one that will provide version's information (related to #607).
Not sure if this is a useful addition unless we plan to add a minimal user interface for the Renku team members to easily add/browse the maintenances.

[emmjab]

A more complex solution would use an array of maintenances with a start and a end timestamp. The UI can show the maintenance page during these hours, as well as a warning message in the Landing page for a while (2 days?) before the event.

I think this is critical so users are aware it's coming and can save everything in time.

[ciyer]

I think adding a variable in the chart is a good solution for showing the maintenance page.

Another way of informing users about future maintenance is to use the GitLab broadcast functionality:

https://docs.gitlab.com/ee/user/admin_area/broadcast_messages.html
https://docs.gitlab.com/ee/api/broadcast_messages.html

This already offers a UI for specifying a message with start/end dates for validity.

[lorenzo-cavazzi]

@ciyer I agree, that is a nice solution, it would be very flexible for displaying any type of custom messages and everything will be stored in GitLab.

On the other hand, this would require the DevOps member to add the maintenance to both GitLab and the chart (or setting the chart variable true at the beginning and false at the end of the maintenance) -- not a great burden, we could go that way and then change it later if we don't like it.
Showing the broadcast messages in the Landing page may by useful also for other cases.

[rokroskar]

The broadcast message requires admin access to gitlab which may not always be possible so we shouldn't rely on that mechanism IMO.

[ciyer]

Is there a scenario where the person doing the maintenance does not have admin rights on GitLab?

[rokroskar]

Yes, if it's an external gitlab instance. Not an issue atm for any deployment that I am aware of, but we're trying to work under the assumption that renku does not need admin rights to gitlab in general.