distribution/xfer: make off-by-one error a feature
maxDownloadAttempts maps to the daemon configuration flag --max-download-attempts int Set the max download attempts for each pull (default 5) and the daemon configuration machinery interprets a value of 0 as "apply the default value" and not a valid user value (config validation/ normalization bugs notwithstanding). The intention is clearly that this configuration value should be an upper limit on the number of times the daemon should try to download a particular layer before giving up. So it is surprising to have the configuration value interpreted as a _retry_ limit. The daemon will make up to N+1 attempts to download a layer! This also means users cannot disable retries even if they wanted to. As this is a longstanding bug, not a recent regression, it would not be appropriate to backport the fix (97921915a8
) in a patch release. Update the test to assert on the buggy behaviour so it passes again. Signed-off-by: Cory Snider <csnider@mirantis.com> (cherry picked from commit938ed9a1ed
) Signed-off-by: Cory Snider <csnider@mirantis.com>
This commit is contained in:
parent
2a69cc6e75
commit
c322779dce
1 changed files with 1 additions and 1 deletions
|
@ -382,7 +382,7 @@ func TestMaxDownloadAttempts(t *testing.T) {
|
|||
name: "max-attempts=5, fail at 6th attempt",
|
||||
simulateRetries: 6,
|
||||
maxDownloadAttempts: 5,
|
||||
expectedErr: "simulating download attempt 5/6",
|
||||
expectedErr: "simulating download attempt 6/6",
|
||||
},
|
||||
{
|
||||
name: "max-attempts=0, fail after 1 attempt",
|
||||
|
|
Loading…
Reference in a new issue