[ 
https://issues.apache.org/jira/browse/HADOOP-16326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gabor Bota updated HADOOP-16326:
--------------------------------
    Description: 
We use LocalMetadataStore MetadataStore implementation in S3Guard only for 
testing. 
Inside it uses Guava's cache for storing metadatas. We try to mimic how dynamo 
should work under the hood, but with every new feature or API modification what 
we do on MetadataStore interface level it gets more and more complicated to 
implement the same feature with different behavior.


I want to start a debate on why we need to remove that, or why we want to keep 
it. 
I could rant about why is it annoying to have this implementation when we need 
to get some things right to work with dynamo, and then do a totally different 
set of modification in the LocalMetadata to get the same outcome, and also add 
more tests just for the MetadataStore we use for testing. 


There are also areas in our ever-growing testing matrix that would need more 
attention instead of fixing tests for our test implementation. But on the other 
hand, it is good that we have another impl for the API which we can use for 
drafting new ideas.

  was:
We use LocalMetadataStore MetadataStore implementation in S3Guard only for 
testing. 
Inside it uses Guava's cache for storing metadatas. We try to mimic how dynamo 
should work under the hood, but with every new feature or API modification what 
we do on MetadataStore interface level it gets more and more complicated to 
implement the same feature with different behavior.


I want to start a debate on why we need to remove that, or why we want to keep 
it. 
I could rant about why is it annoying to have this implementation when we need 
to get some things right to work with dynamo, and then do a totally different 
set of modification in the LocalMetadata to get the same outcome, and also add 
more tests just for the MetadataStore we use for testing. There are also areas 
in our ever-growing testing matrix that would need more attention instead of 
fixing tests for our test implementation. But on the other hand, it is good 
that we have another impl for the API which we can use for drafting new ideas.


> S3Guard: Remove LocalMetadataStore
> ----------------------------------
>
>                 Key: HADOOP-16326
>                 URL: https://issues.apache.org/jira/browse/HADOOP-16326
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs/s3
>    Affects Versions: 3.3.0
>            Reporter: Gabor Bota
>            Priority: Minor
>
> We use LocalMetadataStore MetadataStore implementation in S3Guard only for 
> testing. 
> Inside it uses Guava's cache for storing metadatas. We try to mimic how 
> dynamo should work under the hood, but with every new feature or API 
> modification what we do on MetadataStore interface level it gets more and 
> more complicated to implement the same feature with different behavior.
> I want to start a debate on why we need to remove that, or why we want to 
> keep it. 
> I could rant about why is it annoying to have this implementation when we 
> need to get some things right to work with dynamo, and then do a totally 
> different set of modification in the LocalMetadata to get the same outcome, 
> and also add more tests just for the MetadataStore we use for testing. 
> There are also areas in our ever-growing testing matrix that would need more 
> attention instead of fixing tests for our test implementation. But on the 
> other hand, it is good that we have another impl for the API which we can use 
> for drafting new ideas.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Reply via email to