S3 does not use given login and password

[LeeSmet]

When creating a new S3 service with a given username and password, the actual username and password is different from the ones given

[LeeSmet]

    login = j.data.idgenerator.generateXCharID(8)
    password = j.data.idgenerator.generateXCharID(16)
    data = {
        'farmerIyoOrg': self.data['location'],
        'mgmtNic': {'id': '9bee8941b5717835', 'type': 'zerotier', 'ztClient': 'tf_public'},
        'storageType': 'hdd',
        'storageSize': disk,
        'minioLogin': login,
        'minioPassword': password,
        'nsName': j.data.idgenerator.generateGUID(),
        'dataShards': 4,
        'parityShards': 2,
    }
    s3 = self.api.services.find_or_create(S3_GUID, self.data['txId'], data)
    task = s3.schedule_action('install').wait(die=True)
    credentials = task.result

    task = s3.schedule_action('url')
    task.wait()
    if task.state != 'ok':
        self.logger.error("error retrieving S3 url: \n%s", task.eco.trace)
        return

    urls = task.result
    self.logger.info("s3 installed %s at", urls)

    rp_data = {
        'webGateway': 'web_gateway',
        'domain': '{}.wg01.grid.tf'.format(j.data.idgenerator.generateXCharID(6)),
        'servers': [urls['public']],
    }
    reverse_proxy = self.api.services.find_or_create(REVERSE_PROXY_UID, 'rp-%s' % s3.name, rp_data)
    reverse_proxy.schedule_action('install').wait(die=True)
    reverse_proxy.schedule_action('update_servers', args={'servers': [urls['public']]}).wait(die=True)

    print({'login': login, 'password':password})
    print({'login': credentials['login'], 'password':credentials['password']})

this prints:

{'password': '7jef4n2d6lo5i14d', 'login': 'hx45djq3'}
{'password': 'e1abbbo3ehquwini', 'login': 'dmi5r7o9'}

when logging in to the actual deployed s3, the first set of credentials (the ones generated and added to the service data) don't work, but the second set ( returned by the service install task) do work

[LeeSmet]

Issue was caused by a retry decorator on the method described above, deployment errors (possibly due to bad disks) caused the method to re execute, changing the generated credentials, but the s3 service kept the original ones