[
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 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!
was:
There're 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.
# 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 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!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
