[
https://issues.apache.org/jira/browse/HDDS-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17655599#comment-17655599
]
Uma Maheswara Rao G edited comment on HDDS-7585 at 1/9/23 8:25 AM:
-------------------------------------------------------------------
if someone enable posix.compliant and creates buckets and if someone disables
it means, they don't want the system to support posix paths anymore right? In
that case we just need to warn saying to access the paths, you need to enable
posix.compliant ?
I don't know, it's a good idea to alter those paths by ozone itself. IMO, it
should not modify any user materials. Even if we modify it, old posix users may
not understand the paths if we alter right?
or LS should just work as posix compliant if there are paths with _, but we
don;t allow creating any buckets with _ if we don't enable posix.compliant /
non-s3.compliant. ( does amazon s3 client rejects the paths with _ at client
itself? if yes that's good, pure s3 client users can't even try doing)
Another option is: if someone enabled s3 compliant and there are paths
available in the system, then is it simple to skip the paths with non s3
compliant and give a warning that, "There are non-s3 compliant paths. To view
them, please enable non-s3.compliant".
was (Author: umamaheswararao):
if someone enable posix.compliant and creates buckets and if someone disables
it means, they don't want the system to support posix paths anymore right? In
that case we just need to warn saying to access the paths, you need to enable
posix.compliant ?
If you don't know, it's a good idea to alter those paths by ozone itself. IMO,
it should not modify any user materials. Even if we modify it, old posix users
may not understand the paths if we alter right?
or LS should just work as posix compliant if there are paths with _, but we
don;t allow creating any buckets with _ if we don't enable posix.compliant /
non-s3.compliant. ( does amazon s3 client rejects the paths with _ at client
itself? if yes that's good, pure s3 client users can't even try doing)
Another option is: if someone enabled s3 compliant and there are paths
available in the system, then is it simple to skip the paths with non s3
compliant and give a warning that, "There are non-s3 compliant paths. To view
them, please enable non-s3.compliant".
> Allow Ozone bucket to use non-S3-compliance naming rule
> -------------------------------------------------------
>
> Key: HDDS-7585
> URL: https://issues.apache.org/jira/browse/HDDS-7585
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone CLI, Ozone Filesystem, Ozone Manager
> Reporter: Dave Teng
> Priority: Major
>
> We notice many HDFS migration cases which translate the second level
> directory names to Ozone bucket names.
> However, some characters in the name of directory are +compliant with POSIX+
> convention, but are +not compliant with S3+ naming rule, such as
> {*}underscore{*}.
> Thus the original HDFS path which contains *underscore* _character are not
> allowed to put into Ozone because by default Ozone's path validation is same
> as S3. For such users, this proposal wish to provide a way that when the user
> gives a flag while creating the bucket via Ozone CLI (not from S3 interface),
> Ozone will allow *underscore*_ only for such buckets. The idea is it'd be
> user's choice whether to create a non-s3 compliant bucket path or not. Ozone
> will keep equally supporting both OFS and S3 interfaces. For pure file system
> back ground users, they may want to go ahead with this flag by having the
> awareness of that they may not be able to access the bucket through S3
> interface.
>
> This Jira is an umbrella ticket that makes Ozone compatible with these two
> types of naming convention, both POSIX and S3, to enable the HDFS to Ozone
> migration with non s3 compliant paths.
>
> (ps:
> - This proposal wouldn't change the default behavior of S3 bucket naming
> semantic in Ozone.
> - The documentation for new flag will be provided! )
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
