[FLINK-38717][runtime] Display the load status of TaskManagers.

[RocMarshal]

What is the purpose of the change

• [FLINK-38718][runtime] Display the number of tasks at slots level on the detailed TaskManager page.
• [FLINK-38719][runtime] Display the number of tasks on the TaskManagers page.

Brief change log

• [FLINK-38718][runtime] Display the number of tasks at slots level on the detailed TaskManager page.
• [FLINK-38719][runtime] Display the number of tasks on the TaskManagers page.

Verifying this change

This change added tests and can be verified as follows:

• org.apache.flink.runtime.resourcemanager.ResourceManagerTaskExecutorTest#testRequestTaskManagerDetailsInfo

• integration test result:

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[RocMarshal]

Hi, @ferenc-csaky Could you help take a look ? Thank you !

[flinkbot]

CI report:

• bd645fb Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[ferenc-csaky]

I think assignedTasks instead of numberOfTasks would cover better what this field is intended for.

I do not see why do we need to use LoadingWeight for this. It feels forced to me, and I maybe I miss something, but I also feel it complicates this change for nothing.

[ferenc-csaky]

I'd probably use Assigned Tasks as the table header too. Same for the other components.

[RocMarshal]

Thx! The suggested change would be done after a stable conclusion about the discussion.

[RocMarshal]

I think assignedTasks instead of numberOfTasks would cover better what this field is intended for.

I do not see why do we need to use LoadingWeight for this. It feels forced to me, and I maybe I miss something, but I also feel it complicates this change for nothing.

Thank you @ferenc-csaky for the comments.

Pls let me have a try on clarifying it:

Initially, I did not use LoadingWeight when extending the SlotReport, and only included the numberOfTasks.

Why I switched to LoadingWeight:

• It satisfies the current functional requirements, too.
• One of the motivations behind introducing LoadingWeight is to provide a way to represent and potentially extend more slot-level load information.What I mean is: if we use LoadingWeight as the vehicle for reporting SlotReport data, then in the future, if we want to expose additional load-related information, we won’t need to change the load-related parameter passing chain anymore. The ResourceManager could simply retrieve the desired load metrics directly from LoadingWeight. In short, using an interface-driven approach gives us openness for future extensions. That said, I admit that, relative to the current functionality, this coding approach does violate the principle of minimal changes.

Both approaches are acceptable to me. If you believe that, for the current change, adhering to the minimal change principle should take priority, I'd be happy to revise the implementation accordingly.

[RocMarshal]

Hi @ferenc-csaky May I know your next suggestions or opinion if you had the free time ?
Thank you very much !