[
https://issues.apache.org/jira/browse/HDDS-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338105#comment-17338105
]
Marton Elek commented on HDDS-4944:
-----------------------------------
bq. Here are the implications of this proposal.
Thank you to share this list [~arp]. This is exactly the type of lists which
were missing for my understanding. And it sounds very reasonable (even if we
have a few pro-s on the other side).
But please note that this was just a question why didn't do this, my main
concerns was about the tenant abstraction. Still it's not always required,
because it's possible to start one S3g and identify the default volume (!)
based on the username. It's not necessary to have an additional abstraction. My
suggestion was to create a similar comparison about using the volume only as
the unit of bucket namespace separation without introducing new entries which
would require a new administration toolset. Especially as the account-namespace
isolation seems to be covetable with simple group management. (See my video as
an example).
So here I think we should discuss the multiple options and compare them in the
design doc and explain why the suggested way is the preferred one.
bq. Cluster admins usually do not have privileges to manage their own DNS
infrastructure. Also Hadoop services never run with network administrator
privileges to manage DNS. So how do your users create a DNS entry when a new
bucket is created? Amazon can do this because they control their own
infrastructure.
Please note that we already have support for DNS based bucket naming. Path
based bucket addresses are legacy at AWS, so when Ozone is used as pure S3
compatible object store I can imagine that a wildcard DNS can be used (it's not
required to create new DNS entries for each buckets).
But please note that this argument was about the URL of the buckets. If we need
a separated URL (independent if it includes the bucket name in the path or as
part of the dns) it's not a big deal to have multiple
bq. The best approach in my opinion for multi tenancy at the s3g level is
managing the umber of request/s or throughput/s
Thanks [~msumbul] the suggestion. It's a very interesting question. If the
default volume name for a specific user is identified on the OM side (based on
the credentials) it can be hard to implement it. I think it's possible to do
it, but it means we need a separated mapping between incoming URL and s3v
volumes (tenants?). It can be either DNS based on we can use some additional
fields (like region?) to propagate this information.
Do we have any plan to solve this?
> Multi-Tenant Support in Ozone
> -----------------------------
>
> Key: HDDS-4944
> URL: https://issues.apache.org/jira/browse/HDDS-4944
> Project: Apache Ozone
> Issue Type: New Feature
> Components: Ozone CLI, Ozone Datanode, Ozone Manager, Ozone Recon,
> S3, SCM, Security
> Affects Versions: 1.2.0
> Reporter: Prashant Pogde
> Assignee: Prashant Pogde
> Priority: Major
> Labels: pull-request-available
> Attachments: Apache-S3-compatible-Multi-Tenant-Ozone-short.pdf.gz,
> Ozone MultiTenant Feature _ Requirements and Abstractions-3.pdf, Ozone,
> Multi-tenancy, S3, Kerberos....pdf, UseCaseAWSCompatibility.pdf,
> UseCaseCephCompatibility.pdf, UseCaseConfigureMultiTenancy.png,
> UseCaseCurrentOzoneS3BackwardCompatibility.pdf,
> VariousActorsInteractions.png, uml_multitenant_interface_design.png
>
>
> This Jira will be used to track a new feature for Multi-Tenant support in
> Ozone. Initially Multi-Tenant feature would be limited to ozone-users
> accessing Ozone over S3 interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
