YARN-11938. Integrate Scheduler UI to UI2

[K0K0V0K]

Description of PR

A link should be visible in UI2 nav bar to Scheduler UI, if Scheduler UI enabled.

How was this patch tested?

Deployed to a cluster and turn on the scheduler ui.

For code changes:

• Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
• Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

AI Tooling

If an AI tool was used:

• The PR includes the phrase "Contains content generated by "
  where is the name of the AI tool used.
• My use of AI contributions follows the ASF legal policy
  https://www.apache.org/legal/generative-tooling.html

[hadoop-yetus]

💔 -1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 25s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 0s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+0 🆗	jshint	0m 0s		jshint was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
-1 ❌	test4tests	0m 0s		The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
			_ trunk Compile Tests _
+0 🆗	mvndep	2m 8s		Maven dependency ordering for branch
+1 💚	mvninstall	27m 0s		trunk passed
+1 💚	compile	3m 20s		trunk passed with JDK Ubuntu-21.0.10+7-Ubuntu-124.04
+1 💚	compile	3m 23s		trunk passed with JDK Ubuntu-17.0.18+8-Ubuntu-124.04.1
+1 💚	checkstyle	1m 16s		trunk passed
+1 💚	mvnsite	1m 12s		trunk passed
+1 💚	javadoc	1m 0s		trunk passed with JDK Ubuntu-21.0.10+7-Ubuntu-124.04
+1 💚	javadoc	0m 54s		trunk passed with JDK Ubuntu-17.0.18+8-Ubuntu-124.04.1
+0 🆗	spotbugs	0m 24s		branch/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui no spotbugs output file (spotbugsXml.xml)
+1 💚	shadedclient	15m 42s		branch has no errors when building and testing our client artifacts.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 18s		Maven dependency ordering for patch
+1 💚	mvninstall	1m 29s		the patch passed
+1 💚	compile	3m 12s		the patch passed with JDK Ubuntu-21.0.10+7-Ubuntu-124.04
+1 💚	javac	3m 12s		the patch passed
+1 💚	compile	3m 24s		the patch passed with JDK Ubuntu-17.0.18+8-Ubuntu-124.04.1
+1 💚	javac	3m 24s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
+1 💚	checkstyle	1m 13s		the patch passed
+1 💚	mvnsite	1m 14s		the patch passed
+1 💚	javadoc	0m 50s		the patch passed with JDK Ubuntu-21.0.10+7-Ubuntu-124.04
+1 💚	javadoc	0m 46s		the patch passed with JDK Ubuntu-17.0.18+8-Ubuntu-124.04.1
+0 🆗	spotbugs	0m 17s		hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui has no data from spotbugs
+1 💚	shadedclient	15m 3s		patch has no errors when building and testing our client artifacts.
			_ Other Tests _
-1 ❌	unit	87m 22s	/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt	hadoop-yarn-server-resourcemanager in the patch passed.
+1 💚	unit	1m 0s		hadoop-yarn-ui in the patch passed.
+1 💚	asflicense	0m 37s		The patch does not generate ASF License warnings.
		183m 29s

Reason	Tests
Failed junit tests	hadoop.yarn.server.resourcemanager.webapp.TestRMWebServices

Subsystem	Report/Notes
Docker	ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8301/1/artifact/out/Dockerfile
GITHUB PR	#8301
Optional Tests	dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets jshint
uname	Linux 1a60bb464bec 5.15.0-164-generic #174-Ubuntu SMP Fri Nov 14 20:25:16 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/bin/hadoop.sh
git revision	trunk / d2ce8c5
Default Java	Ubuntu-17.0.18+8-Ubuntu-124.04.1
Multi-JDK versions	/usr/lib/jvm/java-21-openjdk-amd64:Ubuntu-21.0.10+7-Ubuntu-124.04 /usr/lib/jvm/java-17-openjdk-amd64:Ubuntu-17.0.18+8-Ubuntu-124.04.1
Test Results	https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8301/1/testReport/
Max. process+thread count	945 (vs. ulimit of 5500)
modules	C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui U: hadoop-yarn-project/hadoop-yarn
Console output	https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8301/1/console
versions	git=2.43.0 maven=3.9.11 spotbugs=4.9.7
Powered by	Apache Yetus 0.14.1 https://yetus.apache.org

This message was automatically generated.

[pan3793]

@K0K0V0K I see you working actively on the YARN frontend recently, do you guys have an interest in modernizing YARN UI v2? it uses a relatively old tech stack and fails to build many times, especially on new OS.

[Hean-Chhinling]

Thanks for this improvement @K0K0V0K.
LGTM!

[K0K0V0K]

Thanks @Hean-Chhinling for the review!

---

Sure @pan3793 , we are open to that!

Yes, I think the same — the UI is not in the best shape and is somewhat hard to maintain.

Two years ago, I created a UI PoC:
https://github.com/K0K0V0K/yayu

I had a vision that we should move away from JS code and use server side rendering for the following reasons:
• If no JS is running, no vulnerabilities can be introduced through JS code.
• If we don’t have JS dependencies, we don’t need to constantly update them.
• The main language of Hadoop is Java, so if the UI is Java-based, the community could maintain it more easily.
• Writing UI tests for it would also be much easier.

There is a downside regarding the UI experience, but in the context of Hadoop, I suspect users are more focused on security than on having a fancy UI.

However, to be honest, I’m not sure if this is the right approach.
May I ask your opinion about this?

Should we move to a no-JS UI where users can see the cluster state, or should we move to a newer JS framework?

[pan3793]

@K0K0V0K Apologies for my late reply.

Thank you for your efforts and enthusiasm in this direction. I understand the advantages of non-JS, but I think abandoning JS would be a huge step backward in terms of user experience —it's like going back 30 years.

JS's ability to update web pages has a huge impact on user experience. To give a concrete example, the current display of the YARN Agg Log is directly rendered on the server side.

For very long container logs, the browser is very prone to becoming unresponsive. However, when I tried using monaco-editor[1] + JS to retrieve the logs in chunks and incrementally append each log chunk to the monaco-editor, the browsing experience became very smooth, almost like opening a very large text file locally using VS Code.

So, I'm not keen to adopt this no-JS. It would be great if the UIv2 can migrate to the same stack as the newly added Scheduler UI - React, which exhibits extremely strong vitality, and is likely to be popular for many years. However, I may make the wrong judgment because I am not very experienced in the frontend field.

[1] https://github.com/microsoft/monaco-editor

[brumi1024]

@pan3793 Not sure if you have seen, but I've started (and merged) a modern React based Capacity Scheduler config UI, it would be relatively simple to extend that with the remaining feature set of UI2: https://issues.apache.org/jira/browse/YARN-11885

[pan3793]

@brumi1024, Nice!

TBH, I haven't seen a user use YARN UIv2, chime in just because I found it breaks the build several times in recent years, it's really great if you can move it to a modern stack and get rid of legacy packages, especially platform-dependent deps.

BTW, the Scheduler UI looks amazing, I will find time to try it!

[brumi1024]

Thanks @K0K0V0K for the patch and @Hean-Chhinling for the review, merging to trunk.