Must not attempt to set credentials if no S3 bucket is configured

[vetinari]

Without a configured S3 bucket to store the credentials, mint should not attempt to create a password, it would be unusable anyway (and the way it works now the passwords accumulate).

[prayerslayer]

Accumulated passwords only happen when we can’t write to any configured bucket (because it doesn’t exist or permissions are not set correctly).

Proposed solution: We try to write to S3 n times max. When a write was successful, we reset the counter to 0. After n tries client and password rotation is paused until manually unpaused via YOUR TURN.

[vetinari]

what about checking the writeability of the bucket before attempting to call? if that fails, just do something if there are changes to that user (or unpaused via yourturn)

[sarnowski]

The only check that we can do to really validate if the future write will work is to write to both, user.json and client.json. And as we don't store passwords, we have no way of regenerating the same files again. Every other write check will not be perfectly safe and so we should choose the other strategy as this works always, in any case.

[prayerslayer]

This implements both strategies:

• First it checks whether all buckets are writable in theory (writes a file to the bucket). If this fails, increments s3_errors and does nothing else.
• If it succeeds, it writes client/user credentials to the buckets — again, if one write fails, it increments the counter and does not commit the password at the Service User API.
• Only if the test write to all buckets as well as the actual write to all buckets succeed does it commit at the Service User API.
• Skips every update if s3_errors is greater than 10.