[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