Skip to content

HDDS-3858. Remove support to start Ozone and HDFS datanodes in the same JVM #1117

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.

Sign up for GitHub

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

Jump to bottom
Merged
elek merged 2 commits into from
Jun 25, 2020
Merged

HDDS-3858. Remove support to start Ozone and HDFS datanodes in the same JVM #1117

elek merged 2 commits into from
Jun 25, 2020

Conversation

@elek
Copy link
Member

@elek elek commented Jun 23, 2020

What changes were proposed in this pull request?

With a few thousands issues ago Ozone was integral part of Hadoop/HDFS project. At that time there were two options to start datanode:

  1. Start in a separated JVM

  2. Start in the same JVM with the HDFS

Today only 1 is the standard way, this is tested and working. 2nd is not working any more but still documented.

I propose to drop the support of this use case as I can't see any benefit to support it anymore:

  1. I think 100% of the users will use Ozone as a separated process not as a HDFS Datanode plugin
  2. Fixing the classpath issues is significant effort as the classpath of HDFS and Ozone are diverged.

What is the link to the Apache JIRA

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

How was this patch tested?

Not required. One compose folder + docs are removed.

@elek
Copy link
Member Author

elek commented Jun 23, 2020

Ping everybody (especially @jnp @arp7 @xiaoyuyao @mukul1987 @nandakumar131 )

@dineshchitlangia
Copy link
Contributor

dineshchitlangia commented Jun 23, 2020 •
edited
Loading

This is a double edged sword :)
Some of my customers that I speak to have indicated they would not directly go to Ozone in an independent fashion and a few of them have indicated they want to explore Ozone by itself.
How about we leave it as is and mention a cautionary statement to indicate that Ozone HDFS Datanode Plugin is now an experimental feature and it not recommended from Production use.
This will allow some users to get their feet wet with ozone in a limited way (if it works to some extent).

@jnp
Copy link
Contributor

jnp commented Jun 23, 2020

The option to run them in same JVM was allowed, to support in-place upgrade from HDFS to Ozone in future. It was assumed that having the two Datanodes in the same JVM will certainly simplify Hdfs to Ozone upgrade.
Some design work happened in past, but not much progress since then. However, that is still a valid goal, IMO.
Once users are comfortable to switch to Ozone completely, an in-place upgrade option will be desirable to avoid data copy, and will be a way faster option to move to Ozone.

@xiaoyuyao
Copy link
Contributor

xiaoyuyao commented Jun 23, 2020

@elek thanks for bringing this up. Given the fact that it is broken currently, it makes sense to remove the document saying it is supported. Let's open a separate JIRA to track the issues such as classpath, etc. that prevent running HDDS datanode as plugin inside HDFS datanode JVM. They need to be fixed when we revisit in-place upgrade.

@elek
Copy link
Member Author

elek commented Jun 23, 2020 •
edited
Loading

The option to run them in same JVM was allowed, to support in-place upgrade from HDFS to Ozone in future

@jnp Base on the last design in-place upgrade can work with different JVM on the same host. And it's possible to run HDFS and Ozone datanodes on the same node.

My problem is that maintaining this feature requires significant effort. If we would like to do it, it's a release blocker:

2020-06-23 15:22:52 WARN  DataNode:983 - ServicePlugin org.apache.hadoop.ozone.HddsDatanodeService@5226e402 could not be started
java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V

Ozone HDFS Datanode Plugin is now an experimental feature

We can call it as a broken feature ;-)

@elek
Copy link
Member Author

elek commented Jun 23, 2020

/pending "Blocking merge ability as we definitely need an agreement first. Possible topic for Community Meeting."

github-actions[bot]
github-actions bot previously requested changes Jun 23, 2020
View reviewed changes
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Marking this issue as un-mergeable as requested.

Please use /ready comment when it's resolved.

"Blocking merge ability as we definitely need an agreement first. Possible topic for Community Meeting."

@jnp
Copy link
Contributor

jnp commented Jun 23, 2020

Given the fact that it is broken currently, it makes sense to remove the document saying it is supported.

I agree.

@arp7
Copy link
Contributor

arp7 commented Jun 23, 2020

+1 for documenting that this is not supported.

@maobaolong
Copy link
Member

maobaolong commented Jun 24, 2020

+1, it will make Ozone repo clearly.

@elek
Copy link
Member Author

elek commented Jun 24, 2020

+1 for documenting that this is not supported.

Yes, it's important that I wouldn't like to modify interfaces or code. Just remove visibility (remove docs + compose examples).

We can make it work any time, or we can provide specific plugin for in-place upgrade.

It seems that we have an agreement that we can hide this feature, and we can further discuss long-term strategies before any code change.

As we have the consensus, I will merge this PR, soon.

@elek
Copy link
Member Author

elek commented Jun 24, 2020

/ready

@github-actions github-actions bot dismissed their stale review June 24, 2020 09:43

Blocking review request is removed.

@github-actions github-actions bot removed the pending label Jun 24, 2020
@elek elek merged commit 8235366 into apache:master Jun 25, 2020
errose28 added a commit to errose28/ozone that referenced this pull request Jun 25, 2020
@errose28
Merge remote-tracking branch 'upstream/master'
615f58c 
* upstream/master: (56 commits)
  HDDS-3264. Fix TestCSMMetrics.java. (apache#1120)
  HDDS-3858. Remove support to start Ozone and HDFS datanodes in the same JVM (apache#1117)
  HDDS-3704. Update all the documentation to use ozonefs-hadoop2/3 instead of legacy/current (apache#1099)
  HDDS-3773. Add OMDBDefinition to define structure of om.db. (apache#1076)
  Revert "HDDS-3263. Fix TestCloseContainerByPipeline.java. (apache#1119)" (apache#1126)
  HDDS-3821. Disable Ozone SPNEGO should not fall back to hadoop.http.a… (apache#1101)
  HDDS-3819. OzoneManager#listVolumeByUser ignores userName parameter when ACL is enabled (apache#1087)
  HDDS-3779. Add csi interface documents to show how to use ozone csi (apache#1059)
  HDDS-3857. Datanode in compose/ozonescripts can't be started (apache#1116)
  HDDS-3430. Enable TestWatchForCommit test cases. (apache#1114)
  HDDS-3263. Fix TestCloseContainerByPipeline.java. (apache#1119)
  HDDS-3512. s3g multi-part-upload saved incorrect content using streaming (apache#1092)
  HDDS-3836. Modify ContainerPlacementPolicyFactory JavaDoc (apache#1097)
  HDDS-3780. Replace the imagePullPolicy from always to IfNotPresent (apache#1055)
  HDDS-3847. Change OMNotLeaderException logging to DEBUG (apache#1118)
  HDDS-3745. Improve OM and SCM performance with 64% by avoid collect datanode information to s3g (apache#1031)
  HDDS-3286. BasicOzoneFileSystem  support batchDelete. (apache#814)
  HDDS-3850. Update the admin document to let user know how to show the status of all rules. (apache#1109)
  HDDS-3848. Add ratis.thirdparty.version in main pom.xml (apache#1108)
  HDDS-3815. Avoid buffer copy in ContainerCommandRequestProto. (apache#1085)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@github-actions github-actions[bot] github-actions[bot] left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@elek @dineshchitlangia @jnp @xiaoyuyao @arp7 @maobaolong