[
https://issues.apache.org/jira/browse/HADOOP-17771?focusedWorklogId=613921&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-613921
]
ASF GitHub Bot logged work on HADOOP-17771:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jun/21 09:48
Start Date: 23/Jun/21 09:48
Worklog Time Spent: 10m
Work Description: steveloughran commented on pull request #3133:
URL: https://github.com/apache/hadoop/pull/3133#issuecomment-866694906
One thought here: would you ever want the s3a connector to fall back to that
bundled region lookup sequence?
I'm wondering in particular if it makes a difference in routing/billing on
EC2 deployments?
As of Hadoop 3.3.1 if region=null, endpoint=null the Ec2 metadata is used to
provide the region info (this is new).
With this patch. if endpoint = null we switch to saying region = us-east-1
will that do bad things for signing/routing HTTP connections in an EC2
deployment in different regions?
For example, if I am running in AWS ireland, will this cause requests to go
to us-east-1, even if they then end up redirected back to eu-west-1.
this could mean connections are slower to set up, risk of remote data
transfer and billing (though the redirections should fix that, right?), and if
the rules for a deployment prevent out-of-region network traffic, will this
break. I think we have hit problems related to this in the past.
put differently: is anything special happening with the default "null"
endpoint and Ec2 metadata region name provision which we need to know about and
support? If so, we could allow the region to be set to "" or maybe "ec2" and
have that revert to the resolve chain
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 613921)
Time Spent: 1h 20m (was: 1h 10m)
> S3AFS creation fails without region set in ~/.aws/config
> --------------------------------------------------------
>
> Key: HADOOP-17771
> URL: https://issues.apache.org/jira/browse/HADOOP-17771
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 3.3.1
> Environment: Host outside EC2 and without the file ~/.aws/config or
> without a region set in it
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Blocker
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> If you don't have {{fs.s3a.endpoint}} set and lack a region set in
> env var {{AWS_REGION_ENV_VAR}}, system property {{aws.region}} or the file
> ~/.aws/config
> then S3A FS creation fails with the message
> "Unable to find a region via the region provider chain."
> This is caused by the move to the AWS S3 client builder API in HADOOP-13551
> This is pretty dramatic and no doubt everyone will be asking "why didn't you
> notice this?",
> But in fact there are some reasons.
> # when running in EC2, all is well. Meaning our big test runs were all happy.
> # if a developer has fs.s3a.endpoint set for the test bucket, all is well.
> Those of us who work with buckets in the "regions tend to do this, not
> least because it can save a HEAD request every time an FS is created.
> # if you have a region set in ~/.aws/config then all is well
> reason #3 is the real surprise and the one which has really caught out. Even
> my tests against buckets in usw-2 through central didn't fail because of
> course I, like my colleagues, have the AWS S3 client installed locally. This
> was sufficient to make the problem go away. It is also why this has been an
> intermittent problem on test clusters outside AWS infra: it really depended
> on the VM/docker image whether things worked or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
