hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharat Viswanadham (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDDS-807) Period should be an invalid character in bucket names
Date Mon, 05 Nov 2018 19:33:00 GMT

    [ https://issues.apache.org/jira/browse/HDDS-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675662#comment-16675662

Bharat Viswanadham commented on HDDS-807:

Thank You [~arpitagarwal] for the proposal.

This looks good to me.


So, we want to support 3 different models.
 # If the user, provides URL like this, *o3fs://bucket.volume/key* so we get OM address
from config?
 # For other 2 cases, we get from the URI.

So, is my understanding correct?


> Period should be an invalid character in bucket names
> -----------------------------------------------------
>                 Key: HDDS-807
>                 URL: https://issues.apache.org/jira/browse/HDDS-807
>             Project: Hadoop Distributed Data Store
>          Issue Type: Improvement
>            Reporter: Arpit Agarwal
>            Priority: Critical
> ozonefs paths use the following syntax:
> - o3fs://bucket.volume/..
> The OM host and port are read from configuration. We cannot specify a target filesystem
with a fully qualified path. E.g. _o3fs://bucket.volume.om-host.example.com:9862/. Hence we
cannot hand a fully qualified URL with OM hostname to a client without setting up config files
beforehand. This is inconvenient. It also means there is no way to perform a distcp from one
Ozone cluster to another.
> We need a way to support fully qualified paths with OM hostname and port _bucket.volume.om-host.example.com_.
If we allow periods in bucketnames, then such fully qualified paths cannot be parsed unambiguously.
However if er disallow periods, then we can support all of the following paths unambiguously.
>  # *o3fs://bucket.volume/key* - The authority has only two period-separated components.
These must be bucket and volume name respectively.
>  # *o3fs://bucket.volume.om-host.example.com/key* - The authority has more than two components.
The first two must be bucket and volume, the rest must be the hostname.
>  # *o3fs://bucket.volume.om-host.example.com:5678/key* - Similar to #2, except with a
port number.
> Open question is around HA support. I believe for HA we will have to introduce the notion
of a _nameservice_, similar to HDFS nameservice. This will allow a fourth kind of Ozone URL:
>  - *o3fs://bucket.volume.ns1/key* - How do we distinguish this from #3 above? One way
could be to find if _ns1_ is known as an Ozone nameservice via configuration. If so then treat
it as the name of an HA service. Else treat it as a hostname.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message