4 ms·
I'm no expert but from a quick glance at https://www.pulumi.com/docs/concepts/state/#using-a-self-managed-backend https://www.pulumi.com/docs/concepts/state/#us
by erik_seaberg 2y ago
I'm no expert but from a quick glance at https://www.pulumi.com/docs/concepts/state/#using-a-self-managed-backend https://www.pulumi.com/docs/concepts/state/#using-a-self-man... it looks like this might work:
client A lists s3://bucket/prefix/.pulumi/locks/, sees nothing
client B lists s3://bucket/prefix/.pulumi/locks/, sees nothing
client A creates s3://bucket/prefix/.pulumi/locks/unique1.json
client A lists s3://bucket/prefix/.pulumi/locks/, only sees unique1.json, and proceeds
client B creates s3://bucket/prefix/.pulumi/locks/unique2.json
client B lists s3://bucket/prefix/.pulumi/locks/ and sees both unique1.json and unique2.json
client B assumes it lost a race, deletes s3://bucket/prefix/.pulumi/locks/unique2.json, and retries
There's another mode where both clients pessimistically retry, but fuzzing a retry delay could eventually choose a winner randomly.
- fishnchips 2y agoIn this case you have the opposite issue, with no-one actually guaranteed to get a lock even though nothing is holding one. Fuzzed retries may work in practice but theoretically speaking this is a flawed algorithm.
- erik_seaberg 2y agoHm, I can sort of imagine a way to use lockfile names to claim a random position in a queue of pending changes, but I don't know if anyone has been worried enough to do that. In practice Pulumi seems to give up instead of retrying: https://github.com/pulumi/docs/issues/11679 https://github.com/pulumi/docs/issues/11679