[tahoe-lafs-trac-stream] [tahoe-lafs] #2068: cloud.s3 backend: investigate DNS failures; possibly fall back to bucket-in-path for retries if bucket-in-host fails
tahoe-lafs
trac at tahoe-lafs.org
Thu Aug 29 13:21:41 UTC 2013
#2068: cloud.s3 backend: investigate DNS failures; possibly fall back to bucket-
in-path for retries if bucket-in-host fails
-------------------------+-------------------------------------------------
Reporter: daira | Owner: daira
Type: defect | Status: new
Priority: normal | Milestone: undecided
Component: code- | Version: cloud-branch
storage | Keywords: s3-backend ec2 dns
Resolution: | LeastAuthority.com error txaws reliability
Launchpad Bug: |
-------------------------+-------------------------------------------------
Description changed by daira:
Old description:
> LeastAuthority.com's monitoring sees occasional DNS errors
> [https://github.com/LeastAuthority/leastauthority.com/issues/30] when
> trying to resolve $BUCKETNAME.s3.amazonaws.com from an EC2 instance. It
> could fall back to a bucket-in-path URL for retries in this case.
> Alternatively, it may be that the existing retry is sufficient to mask
> these failures, but we need to know whether that is the case. (The
> monitoring code does not retry.)
>
> (We originally switched to bucket-in-host URLs because bucket-in-path
> requests were sometimes failing, claiming that we were using the wrong
> endpoint. If that happens in the same situation as the DNS failures, then
> we might not be able to improve reliability by falling back to bucket-in-
> path.)
New description:
!LeastAuthority.com's monitoring sees occasional DNS errors
[https://github.com/LeastAuthority/leastauthority.com/issues/30] when
trying to resolve $BUCKETNAME.s3.amazonaws.com from an EC2 instance. It
could fall back to a bucket-in-path URL for retries in this case.
Alternatively, it may be that the existing retry is sufficient to mask
these failures, but we need to know whether that is the case. (The
monitoring code does not retry.)
(We originally switched to bucket-in-host URLs because bucket-in-path
requests were sometimes failing, claiming that we were using the wrong
endpoint. If that happens in the same situation as the DNS failures, then
we might not be able to improve reliability by falling back to bucket-in-
path.)
--
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2068#comment:1>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list