# PR#70: tools/deploy-rootfs Needs Two Connections and Retries a Refused One

> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

## Related Links

- [PR#69](https://git.javagil.de/mi/werkrevisor/pulls/69): release tools keep only the two newest archives.

## The Problem

The first deploy with `tools/deploy-rootfs` of PR#69 uploaded 0.31.3 and switched all four repositories on mih09.
Then the host refused the next ssh connections, so the script removed no old archive.
It opened eight connections in a row: the upload, the checksum, one per repository, and three for the cleanup.
The webspace refuses connections that follow too quickly.

## Non-Goals

- No change to what the script deploys, keeps or removes.

## The Scenarios

### Feature: a deploy survives a host that refuses quick connections

#### Scenario#70.01: the deploy opens only two connections

So that the host has no reason to refuse one.

- **Given** an archive and four repositories on one host
- **When** the deploy runs
- **Then** it connects to the host twice: once for the upload and once for all other steps

##### Verified by

- A test against a local directory instead of a host, with `scp` and `ssh` replaced by local commands:
  the archive in use by a second repository stays, the two newest archives stay,
  a backup without a version stays, and a second deploy keeps the first backup.

#### Scenario#70.02: a refused connection is tried again

So that a short block of the host does not leave a half-finished deploy.

- **Given** a host that refuses the first connections of a deploy
- **When** the deploy runs
- **Then** it waits 30, 60, 90, 120 and 150 seconds before the next attempts
- **And** it gives up after the sixth refused attempt

##### Verified by

- A run against mih09 after the host had refused the first deploy: it switched four repositories,
  removed one archive and 44 backups, and was not refused.
- A local run of `retrying` with a command that always fails: it waits 30 to 150 seconds and then gives up.

## The Solution

- The remote steps run as one script, sent as an argument of a single ssh call,
  so that a retry sends it again; it carries `tools/release_files.py` along.
- `retrying` repeats `scp` and `ssh` after a refused connection, up to six times.
- Version 0.31.4.