[
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 set the flag whether the bucket name
follows S3 or non-S3 naming rule.
- When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
{color:#57d9a3}true{color}, and {color:#4c9aff}server{color} side set
'S3_NAMING_COMPLIANT' as {color:#57d9a3}true{color}. The bucket naming should
*be compliant* with S3 rules.
- When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
{color:#de350b}false{color}, and {color:#4c9aff}server{color} side set
'S3_NAMING_COMPLIANT' as {color:#57d9a3}true{color}. The bucket naming should
be allowed to *NOT* *compliant* with S3 rules.
- When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
{color:#57d9a3}true{color}, and {color:#4c9aff}server{color} side set
'S3_NAMING_COMPLIANT' as {color:#de350b}false{color}. The bucket naming should
*be compliant* with S3 rules.
- When a {color:#4c9aff}client {color}set 'S3_NAMING_COMPLIANT' as
{color:#de350b}false{color}, and {color:#4c9aff}server{color} side set
'S3_NAMING_COMPLIANT' as {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 their need without affecting
other clients bucket naming rule. 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 set 'S3_NAMING_COMPLIANT' as
{color:#57d9a3}true{color}. The bucket naming should *be compliant* with S3
rules {+}*For All Clients*{+}.
* When {color:#4c9aff}server{color} side set 'S3_NAMING_COMPLIANT' as
{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. Not involved the client side.
* The {color:#ffab00}disadvantage{color} is that all buckets created in same
Ozone cluster don't have flexibility to have different S3-naming compliant or
non-S3-naming compliant setting.
I currently have a [POC PR|https://github.com/apache/ozone/pull/4037] of the
approach 1, set the flag on both client and server side regarding to whether 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 {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!
> 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 set the flag whether the bucket name
> follows S3 or non-S3 naming rule.
> - When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
> {color:#57d9a3}true{color}, and {color:#4c9aff}server{color} side set
> 'S3_NAMING_COMPLIANT' as {color:#57d9a3}true{color}. The bucket naming should
> *be compliant* with S3 rules.
> - When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
> {color:#de350b}false{color}, and {color:#4c9aff}server{color} side set
> 'S3_NAMING_COMPLIANT' as {color:#57d9a3}true{color}. The bucket naming should
> be allowed to *NOT* *compliant* with S3 rules.
> - When a {color:#4c9aff}client{color} set 'S3_NAMING_COMPLIANT' as
> {color:#57d9a3}true{color}, and {color:#4c9aff}server{color} side set
> 'S3_NAMING_COMPLIANT' as {color:#de350b}false{color}. The bucket naming
> should *be compliant* with S3 rules.
> - When a {color:#4c9aff}client {color}set 'S3_NAMING_COMPLIANT' as
> {color:#de350b}false{color}, and {color:#4c9aff}server{color} side set
> 'S3_NAMING_COMPLIANT' as {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 their need without
> affecting other clients bucket naming rule. 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 set 'S3_NAMING_COMPLIANT' as
> {color:#57d9a3}true{color}. The bucket naming should *be compliant* with S3
> rules {+}*For All Clients*{+}.
> * When {color:#4c9aff}server{color} side set 'S3_NAMING_COMPLIANT' as
> {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. Not involved the client side.
> * The {color:#ffab00}disadvantage{color} is that all buckets created in same
> Ozone cluster don't have flexibility to have different S3-naming compliant or
> non-S3-naming compliant setting.
> I currently have a [POC PR|https://github.com/apache/ozone/pull/4037] of the
> approach 1, set the flag on both client and server side regarding to whether
> 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]
