The more there is data to backup, the more likely something can go wrong.
Running the exporter script several times will copy less and less things
at each run, so it should increase the probability to succeed.

  The monitor stack was refactored and this change was missing on this SR.

@vpelletier says:

    I do not think this is a "slave" instance, but just a sub-instance.

    "slave instance" is a way to pass parameter to a foreign instance. For example,
    frontend is an instance, and a slave instance is the rule given by an unrelated
    partition to make that existing frontend instance direct http://foo.com to 1.2.3.4:80 .

    OTOH, "balancer" is a sub-instance of ERP5's SR base instance (which is typically the root instance also).

/noticed-by @vpelletier (on nexedi/slapos!43)

When originally in 0a446263 (ERP5 and Jupyter integrated together) I added
Jupyter support into ERP5 the parameter for whether to enable/disable it was
declared as boolean in JSON schema but processed as string in instance code,
this way preventing usage of real JSON's boolean.

Fix it.

(also fixing up software/slapos-master/ which copied the files for play in 87d13789)

/noticed-by @vpelletier (on !43)

  Kill -0 were making the promise exit.

  Use 2 different ports on apache for cached slaves, to differ http and https accesses.
  Introduce the parameter https-url (with fallback to url) to include specific https urls,
    if they are different from url.
  Include /HTTPS/ mapping to traffic server to differ the backends based on the input.

  Not all frontend clusers setup uses the same re6stnet network.

Anyway, the repository contains more than just rina-tools.

  If pidfile is empty, the pgrep will fail forever until the pidfile
  is removed, so check if it exist and it is not empty.

  The promise returns too much data into the PIPE, if it is the case, it makes
  the promise much much slower, causing constant timeout

This is implement as a test suite so that it can be automatically on any commit
to rina/slapos repositories.

Currently, the Debian packaging of the kernel only supports Debian Jessie.

Because slapos.core hardcodes a "supervisord.socket", this file happens to be deleted and cause bugs

This solution is better than adding a sleep in a crontab, because it will be a new
date every day

Revert "resilient: new paramater to define the time to sleep before running the backup in the cron job."

This reverts commit 30d1a937.

It includes more debugging lines, not deploying a slapproxy (no need anymore thanks
the free-port selection recipe), and not delegating some work to a cron job.