Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HDDS-2665. Implement new Ozone Filesystem scheme ofs:// #1021

Merged
merged 23 commits into from
Jun 16, 2020
Merged

Conversation

smengcl
Copy link
Contributor

@smengcl smengcl commented Jun 4, 2020

What changes were proposed in this pull request?

Implement a new scheme for Ozone Filesystem where all volumes (and buckets) can be accessed from a single root.

Also known as Rooted Ozone Filesystem.

This PR combines commits in feature branch HDDS-2665-ofs for review and discussion.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-2665

How was this patch tested?

Added FileSystem contract tests for ofs://.

Added new integration tests.

smengcl and others added 20 commits January 30, 2020 12:45
Conflicts:
hadoop-ozone/dist/src/main/smoketest/ozonefs/ozonefs.robot
Conflicts: (HDDS-3385)
hadoop-ozone/integration-test/src/test/java/org/apache/hadoop/ozone/shell/TestOzoneShellHA.java
@smengcl
Copy link
Contributor Author

smengcl commented Jun 5, 2020

Will open up a new jira to fix sonarcloud bugs, and address merge conflicts.

Copy link
Member

@elek elek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to drive this effort @smengcl. Overall it looks good to me. I agree that we are in the last step before the merge.

I have some questions about the code.

(And I feel myself guilty of the conflict, I can explain the changes on the master what I did, or I can help to rebase it.)

@RunWith(PowerMockRunner.class)
@PrepareForTest({ OzoneClientFactory.class, UserGroupInformation.class })
@PowerMockIgnore("javax.management.*")
public class TestRootedOzoneFileSystemWithMocks {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: there is a full, in memory implementation of ObjectStore in s3 project. Can be useful for similar tests if we move it to a common place. (BTW: I like this lightweight test).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed TestRootedOzoneFileSystemWithMocks in HDDS-3767 since TestOzoneFileSystemWithMocks is also removed. We can restore this later.

if (recursive) {
// Delete all buckets first
OzoneVolume volume =
adapterImpl.getObjectStore().getVolume(volumeName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main idea behind the adapter is that we can use only methods on the adapter which provides a clean definition of the used ozone method. I would the usage of getObjectStore() as it leaks the internal methods.

The original goal of adapter to support different classloaders, but still seems to be a good design pattern to use an adapter.getVolume instead.

Copy link
Contributor Author

@smengcl smengcl Jun 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree. When implementing OFS volume and bucket deletion I tried to put the logic in adapter, but I realized if I want to do it the easy way (using recursion) I simply can't put the logic in adapter. Hence the hacky one you see here.

I will refactor this chunk of code and remove adapterImpl in another refactoring jira later. But I think this shouldn't affect the merge.

@smengcl
Copy link
Contributor Author

smengcl commented Jun 9, 2020

Thanks to drive this effort @smengcl. Overall it looks good to me. I agree that we are in the last step before the merge.

I have some questions about the code.

(And I feel myself guilty of the conflict, I can explain the changes on the master what I did, or I can help to rebase it.)

Thanks for the comment @elek .

The merge conflict comes from HDDS-3627 (commit) as far as I can tell. Shouldn't be a big problem. It is always a delight to see good refactoring. :)

A question though. I notice TestOzoneFileSystemWithMocks being removed in HDDS-3627, where in OFS I forked it to create TestRootedOzoneFileSystemWithMocks. Should I relocate the latter to somewhere else or just remove it as well? For now I will move it under hadoop-ozone/ozonefs-common/src/test/java/org/apache/hadoop/fs/ozone/ to be in the same place with TestOzoneFSInputStream.java. The merge conflict resolution work is being done in HDDS-3767.

Conflicts:
hadoop-ozone/ozonefs-hadoop2/src/main/java/org/apache/hadoop/fs/ozone/TestOFSPath.java
hadoop-ozone/ozonefs-hadoop2/src/main/java/org/apache/hadoop/fs/ozone/TestRootedOzoneFileSystemWithMocks.java
hadoop-ozone/ozonefs/src/main/java/org/apache/hadoop/fs/ozone/OzoneClientAdapterFactory.java
@smengcl
Copy link
Contributor Author

smengcl commented Jun 9, 2020

Some of the bugs that showed up in SonarCloud doesn't relate to OFS (e.g. BasicOzoneFileSystem/BasicOzoneClientAdapterImpl).

I will only be addressing the ones in OFS. i.e. BasicRootedOzoneClientAdapterImpl in HDDS-3767.

A closer look reveals that the bug isn't really a bug. If I "address" it by closing ozoneOutputStream in finally, the returning OzoneFSOutputStream will contain a stream that is already closed.

smengcl added a commit to smengcl/hadoop-ozone that referenced this pull request Jun 9, 2020
@codecov-commenter
Copy link

codecov-commenter commented Jun 11, 2020

Codecov Report

Merging #1021 into master will increase coverage by 0.08%.
The diff coverage is 71.82%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1021      +/-   ##
============================================
+ Coverage     70.48%   70.57%   +0.08%     
- Complexity     9260     9405     +145     
============================================
  Files           961      965       +4     
  Lines         48177    48979     +802     
  Branches       4678     4790     +112     
============================================
+ Hits          33959    34565     +606     
- Misses        11968    12104     +136     
- Partials       2250     2310      +60     
Impacted Files Coverage Δ Complexity Δ
...main/java/org/apache/hadoop/ozone/OzoneConsts.java 84.21% <ø> (ø) 1.00 <0.00> (ø)
...e/hadoop/fs/ozone/BasicOzoneClientAdapterImpl.java 70.05% <0.00%> (-0.38%) 28.00 <0.00> (ø)
...g/apache/hadoop/fs/ozone/BasicOzoneFileSystem.java 75.24% <ø> (ø) 51.00 <0.00> (ø)
.../hadoop/fs/ozone/RootedOzoneClientAdapterImpl.java 41.66% <41.66%> (ø) 2.00 <2.00> (?)
...op/fs/ozone/BasicRootedOzoneClientAdapterImpl.java 68.45% <68.45%> (ø) 47.00 <47.00> (?)
...he/hadoop/fs/ozone/BasicRootedOzoneFileSystem.java 74.40% <74.40%> (ø) 50.00 <50.00> (?)
.../main/java/org/apache/hadoop/fs/ozone/OFSPath.java 79.59% <79.59%> (ø) 37.00 <37.00> (?)
...hdds/scm/container/common/helpers/ExcludeList.java 83.67% <0.00%> (-14.29%) 20.00% <0.00%> (-4.00%)
...che/hadoop/hdds/scm/pipeline/PipelineStateMap.java 83.04% <0.00%> (-4.10%) 45.00% <0.00%> (-3.00%)
...ent/algorithms/SCMContainerPlacementRackAware.java 76.69% <0.00%> (-3.01%) 31.00% <0.00%> (-2.00%)
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c5b0ba6...04dc11c. Read the comment docs.

@smengcl
Copy link
Contributor Author

smengcl commented Jun 12, 2020

The only test failure after HDDS-3767 merge is it-hdds-om TestOzoneManagerHAWithData#testOMRestart, which is a flaky test also seen on master branch: https://elek.github.io/ozone-build-results/
Thanks Marton for this useful page.

@smengcl
Copy link
Contributor Author

smengcl commented Jun 15, 2020

Thanks @elek for kicking off another 2 runs. I just pushed another empty commit for a new run.

We might want to exclude (by rebasing) the empty commits from feature branch when we merge is to master? @elek
My plan is to merge the HDDS-2665-ofs branch to master by running

git merge --no-ff HDDS-2665-ofs

when on master branch, as described in the Merging a feature branch section on [this Hadoop Wiki page|https://cwiki.apache.org/confluence/display/HADOOP2/HowToCommit].

@sonarcloud
Copy link

sonarcloud bot commented Jun 16, 2020

SonarCloud Quality Gate failed.

Bug E 2 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 1 Security Hotspot to review)
Code Smell A 38 Code Smells

76.1% 76.1% Coverage
16.9% 16.9% Duplication

warning The version of Java (1.8.0_232) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here

@smengcl
Copy link
Contributor Author

smengcl commented Jun 16, 2020

The last run (merge commit) is good. Will manually merge feature branch HDDS-2665-ofs shortly and close this PR.

@asfgit asfgit merged commit 75de083 into master Jun 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client enhancement New feature or request
Projects
None yet
6 participants