Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 15 Sep 2016 22:09:22 +0000 (UTC)
From: "Aaron Fabbri (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12994117.1470096020000.584807.1473977362181@Atlassian.JIRA>
In-Reply-To: <JIRA.12994117.1470096020000@Atlassian.JIRA>
References: <JIRA.12994117.1470096020000@Atlassian.JIRA> <JIRA.12994117.1470096020365@arcas>
Subject: [jira] [Commented] (HADOOP-13448) S3Guard: Define MetadataStore
 interface.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 15 Sep 2016 22:09:24 -0000


    [ https://issues.apache.org/jira/browse/HADOOP-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15494659#comment-15494659 ] 

Aaron Fabbri commented on HADOOP-13448:
---------------------------------------

Another design question.  I'd like to propose we require all clients to supply absolute paths to the MetadataStore.

Why?

I just tried to support a combination of relative and absolute paths in the LocalMetadataStore.  I wrote some new tests and found that:

- This requires both MetadataStore and DirListingMetadata to be able to resolve relative and absolute paths.  I feel better separation is to leave this to the FileSystem clients: they already have to deal with this.    DirListingMetadata should be a stupid container, not something that knows how to resolve relative paths against working dirs.  If DirListingMetadata#put() can take a relative path, then it needs to resolve it against the working dir so it can ensure it is a proper child of the dir path. The working dir may differ between clients sharing a metadata store.  This implies that implementations need to track an absolute path in addition to the relative one allowed in the DirListingMetadata.  This is extra complexity, garbage, etc.

- In general the logic becomes more error-prone to handle correctly when both types of paths are allowed.

- FileSystem clients (i.e. s3a) already have to do this logic.  

In short, I propose that methods in MetadataStore and DirListingMetadata which take a path will use Precondition checks to enforce that those paths are absolute.  Thoughts [~cnauroth]?

> S3Guard: Define MetadataStore interface.
> ----------------------------------------
>
>                 Key: HADOOP-13448
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13448
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>            Reporter: Chris Nauroth
>            Assignee: Chris Nauroth
>             Fix For: HADOOP-13345
>
>         Attachments: HADOOP-13448-HADOOP-13345.001.patch, HADOOP-13448-HADOOP-13345.002.patch, HADOOP-13448-HADOOP-13345.003.patch, HADOOP-13448-HADOOP-13345.004.patch, HADOOP-13448-HADOOP-13345.005.patch
>
>
> Define the common interface for metadata store operations.  This is the interface that any metadata back-end must implement in order to integrate with S3Guard.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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