[
https://issues.apache.org/jira/browse/HDDS-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Teng updated HDDS-7586:
----------------------------
Description:
There're currently two ideas to approach this problem:
# Allows both the {color:#4c9aff}Ozone client side{color} and
{color:#4c9aff}server{color} side to configure whether to use S3 or non-S3
naming rule.
- When a {color:#4c9aff}CLI/SDK{color} configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}, and
{color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
naming should *be compliant* with S3 rules.
- When a {color:#4c9aff}CLI/SDK{color} configured with property
'is-following-S3-naming-compliance' to {color:#de350b}false{color}, and
{color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
naming should be allowed to *NOT* *compliant* with S3 rules.
- When a {color:#4c9aff}CLI/SDK{color} configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}, and
{color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#de350b}false{color}. The bucket
naming should *be compliant* with S3 rules.
- When a {color:#4c9aff}CLI/SDK {color}configured with property
'is-following-S3-naming-compliance' to {color:#de350b}false{color}, and
{color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
naming should be allowed to *NOT* *compliant* with S3 rules.
* The {color:#00875a}advantage{color} is that different client could
enable/disable S3 naming rule compliance based on requirement. This provide
flexibility especially for HDFS migration.
* The {color:#ffab00}disadvantage{color} is that besides bucket creation,
other type of bucket/key operation (For example, get a bucket, delete a bucket,
set bucket quota, set bucket replication config, etc.) requires the
verification of bucket name as well. Thus we need to make codes change both on
client and server side for each affected operation.
2. Configure only Ozone {color:#4c9aff}server{color} side to whether use S3 or
non-S3 naming rule or not.
- When {color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
naming should *be compliant* with S3 rules {+}*For All Clients*{+}.
* When {color:#4c9aff}server{color} side configured with property
'is-following-S3-naming-compliance' to {color:#de350b}false{color}. The bucket
naming should be allowed to *NOT* *compliant* with S3 rules {+}*For All
Clients*{+}.
* The {color:#00875a}advantage{color} is that the code change only includes
the server side of codes. Not involved the client side.
* The {color:#ffab00}disadvantage{color} is that all the bucket created in
same Ozone cluster can't have different naming rule.
I currently have a [POC PR|https://github.com/apache/ozone/pull/4037] of the
approach 1., allow both client and server side could configure whether or not
to use S3 naming during {*}bucket creation{*}. I'd love to hear any feedback
from the community!
Thank you!
was:
There're currently two ideas to approach this problem:
# Allows both the Ozone client side and server side to configure whether to
use S3 or non-S3 naming rule.
- When a CLI/SDK configured with property 'is-following-S3-naming-compliance'
to true, and server side configured with property
'is-following-S3-naming-compliance' to true. The bucket naming should be
compliant with S3 rules.
- When a CLI/SDK configured with property 'is-following-S3-naming-compliance'
to false, and server side configured with property
'is-following-S3-naming-compliance' to true. The bucket naming should be
allowed to *NOT* compliant with S3 rules.
- When a CLI/SDK configured with property 'is-following-S3-naming-compliance'
to true, and server side configured with property
'is-following-S3-naming-compliance' to false. The bucket naming should be
compliant with S3 rules.
- When a CLI/SDK configured with property 'is-following-S3-naming-compliance'
to false, and server side configured with property
'is-following-S3-naming-compliance' to true. The bucket naming should be
allowed to *NOT* compliant with S3 rules.
* The advantage is that different client could enable/disable S3 naming rule
compliance based on requirement. This provide flexibility especially for HDFS
migration.
* The disadvantage is that besides bucket creation, other type of bucket/key
operation (For example, get a bucket, delete a bucket, set bucket quota, set
bucket replication config, etc.) requires the verification of bucket name as
well. Thus we need to make codes change both on client and server side for each
affected operation.
2. Configure only Ozone server side to whether use S3 or non-S3 naming rule or
not.
- When server side configured with property
'is-following-S3-naming-compliance' to true. The bucket naming should be
compliant with S3 rules {*}For All Clients{*}.
* When server side configured with property
'is-following-S3-naming-compliance' to false. The bucket naming should be
allowed to *NOT* compliant with S3 rules {*}For All Clients{*}.
* The advantage is that the code change only includes the server side of
codes. Not involved the client side.
* The disadvantage is that all the bucket created in same Ozone cluster can't
have different naming rule.
I have a [POC PR|https://github.com/apache/ozone/pull/4037] of the approach 1.,
allow both client and server side could configure whether to use S3 naming
during bucket creation or not. I'd love to hear any feedback from the
community! Thank you!
> Allow users to create an Ozone bucket with non-s3-naming-convention
> -------------------------------------------------------------------
>
> Key: HDDS-7586
> URL: https://issues.apache.org/jira/browse/HDDS-7586
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Dave Teng
> Assignee: Dave Teng
> Priority: Major
> Labels: ozone, pull-request-available
>
> There're currently two ideas to approach this problem:
> # Allows both the {color:#4c9aff}Ozone client side{color} and
> {color:#4c9aff}server{color} side to configure whether to use S3 or non-S3
> naming rule.
> - When a {color:#4c9aff}CLI/SDK{color} configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}, and
> {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
> naming should *be compliant* with S3 rules.
> - When a {color:#4c9aff}CLI/SDK{color} configured with property
> 'is-following-S3-naming-compliance' to {color:#de350b}false{color}, and
> {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
> naming should be allowed to *NOT* *compliant* with S3 rules.
> - When a {color:#4c9aff}CLI/SDK{color} configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}, and
> {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#de350b}false{color}. The
> bucket naming should *be compliant* with S3 rules.
> - When a {color:#4c9aff}CLI/SDK {color}configured with property
> 'is-following-S3-naming-compliance' to {color:#de350b}false{color}, and
> {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
> naming should be allowed to *NOT* *compliant* with S3 rules.
> * The {color:#00875a}advantage{color} is that different client could
> enable/disable S3 naming rule compliance based on requirement. This provide
> flexibility especially for HDFS migration.
> * The {color:#ffab00}disadvantage{color} is that besides bucket creation,
> other type of bucket/key operation (For example, get a bucket, delete a
> bucket, set bucket quota, set bucket replication config, etc.) requires the
> verification of bucket name as well. Thus we need to make codes change both
> on client and server side for each affected operation.
> 2. Configure only Ozone {color:#4c9aff}server{color} side to whether use S3
> or non-S3 naming rule or not.
> - When {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#57d9a3}true{color}. The bucket
> naming should *be compliant* with S3 rules {+}*For All Clients*{+}.
> * When {color:#4c9aff}server{color} side configured with property
> 'is-following-S3-naming-compliance' to {color:#de350b}false{color}. The
> bucket naming should be allowed to *NOT* *compliant* with S3 rules {+}*For
> All Clients*{+}.
> * The {color:#00875a}advantage{color} is that the code change only includes
> the server side of codes. Not involved the client side.
> * The {color:#ffab00}disadvantage{color} is that all the bucket created in
> same Ozone cluster can't have different naming rule.
> I currently have a [POC PR|https://github.com/apache/ozone/pull/4037] of the
> approach 1., allow both client and server side could configure whether or not
> to use S3 naming during {*}bucket creation{*}. I'd love to hear any feedback
> from the community!
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
