Hello, I'm having some trouble getting virtual hosting for S3 Gateway working with my installation through Helm. I'm trying to access as such: -

aws s3 --endpoint-url <https://bucket.s3.my.path.net> ls

It returns the same as base path: -

aws s3 --endpoint-url <https://s3.my.path.net> ls

in that it returns the list of available buckets instead of the contents of the bucket. Is there something wrong with my configuration here? Is the

domain_name

field supposed to be something else? Traffic is being sent to the service, but I can't seem to identify why the bucket is not getting resolved. Below is my

values.yaml

for Helm installation:

lakefsConfig: |
  blockstore:
    type: s3
  gateways:
    s3:
      domain_name: <http://s3.my.path.net|s3.my.path.net>
ingress:
  enabled: true
  ingressClassName: "nginx"
  tls:
  - hosts:
    - <http://my.path.net|my.path.net>
    - <http://s3.my.path.net|s3.my.path.net>
    - "*.<http://s3.my.path.net|s3.my.path.net>"
    secretName: <secret tls>
  hosts:
    - host: <http://my.path.net|my.path.net>
      paths: ["/"]
    - host: <http://s3.my.path.net|s3.my.path.net>
      paths: ["/"]
    - host: "*.<http://s3.my.path.net|s3.my.path.net>"
      paths: ["/"]
  
extraEnvVarsSecret: <secret env>

Thank you!

Hi Carlos! The endpoint should be fixed, and it is up to the AWS CLI to decide when to use the bucket name as a subdomain for the request. If your intention is to see the content of your repository, you can use:

aws s3 --endpoint-url <https://s3.my.path.net> ls <s3://example-repo/>

I was actually trying to just test whether virtual hosting was working correctly with the AWS CLI. My actual issue is trying to run a separate app's (AppSmith) S3 integrations against LakeFS's S3 Gateway. AppSmith uses prefixed requests, but it doesn't seem to function against the LakeFS S3 Gateway as I have it. Is there maybe a simpler way to test this is working on the LakeFS side?

I just tested it and it doesn’t work. Can you please open an issue on GitHub?

Sure, I can do that today. Thanks for your time!

Let me know if any other questions come up 👍

Hey @carlos osuna, let me see if I can try to help. I understand that you have an application trying to access lakeFS using virtual host-style addressing, and it doesn't work. Therefore, you are trying to use the AWS CLI to test your setup. If that is correct, there is a way to do it. Like @Eden Ohana mentioned above, you shouldn't add the bucket name to the endpoint URL. The endpoint URL is always the lakeFS S3 gateway address. To see the contents of your lakeFS repository, use the command Eden attached above. So - how do you force the AWS CLI to use the virtual host-style addressing? You can use the following command to configure the AWS CLI to do so:

aws configure set default.s3.addressing_style virtual

After running this command, requests to lakeFS from the AWS CLI will add the repository name as subdomain.

Thank you, Yoni! Very helpful; I was able to test that and there does seem to be an issue with my virtual hosting.

@carlos osuna you're most welcome. Bonus: add the --debug flag to the aws commands to see a trace of the requests.

Hello! I was wondering when I might receive updates on this. Issue is here: https://github.com/treeverse/lakeFS/issues/3887 I'm not really sure what sort of release schedule the team has for potential bug fixes; any info on that would be appreciated.

Hi Carlos, Let me check on that and get back to you.

@Jonathan Rosenberg FYI: Iddo and I talked to @carlos osuna. When he re-deployed both lakeFS and the PostgreSQL db, issue got resolved. He will let us know if he can reproduce the issue he was facing.

Excellent Thank you!