Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Zhanghao, Thanks for your effort! Best regards, Jing On Tue, Sep 19, 2023 at 8:52 AM Chen Zhanghao wrote: > Thanks to everyone who discussed here, I really appreciate it. I've > updated the FLIP to change all occurrences of "location" to "endpoint" > instead. Given that we've reached

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Thanks to everyone who discussed here, I really appreciate it. I've updated the FLIP to change all occurrences of "location" to "endpoint" instead. Given that we've reached consensus on the topic, I'll restart the voting. Best, Zhanghao Chen 发件人: Rui Fan 发送时间:

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

+1, thanks everyone who discussed here. Best, Rui On Tue, 19 Sep 2023 at 11:41, Chen Zhanghao wrote: > Hi Jing, > > Thanks for the clarification, I now see the point. +1 for using endpoint > now. @fan...@apache.org WDYT? > > Best, > Zhanghao Chen > -- > *发件人:*

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Jing, Thanks for the clarification, I now see the point. +1 for using endpoint now. @fan...@apache.org WDYT? Best, Zhanghao Chen 发件人: Yangze Guo 发送时间: 2023年9月19日 11:18 收件人: dev@flink.apache.org 主题: Re: [DISCUSS] FLIP-363: Unify the

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Thanks for the clarification, Jing. I agree that using another term like endpoint can help us to distinguish it from the existing concept of "location". +1 for using the term endpoint and introducing TaskManagerLocation.getEndpoint(). Best, Yangze Guo On Mon, Sep 18, 2023 at 11:52 PM Jing Ge

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Zhanghao, That is exactly the reason why location should not be used, because there is a clear definition of location in Flink, e.g. TaskManagerLocation which contains more information than hostname+port. If you think endpoint is too generic, how about locationEndpoint? But if we build that

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Yangze, Thanks for your reply! For a subtask, the taskManagerLocation is the physical location. And the task id, operator id and subtask index may be the logical locations of a subtask. Actually, I don't think the taskManagerLocation is a good name here. Unlike task id, operator id, and

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi, Rui, I think the term "location" might be sufficiently clear in the specific context, e.g. SubtaskXXXInfo and TaskManagerXXXInfo. Could you elaborate more on what concept you think one might confuse it with? Best, Yangze Guo On Mon, Sep 18, 2023 at 12:07 PM Rui Fan <1996fan...@gmail.com>

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Zhanghao, > Use a field named "location" (already used in JobExceptionsInfoWithHistory) that represents TaskManager location using the newly added string formatter method. How about using the taskManagerLocation instead of location for all Rest response related classes? The

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi all, I've updated the FLIP to incorporate Yangze's advice: 1. Add a new string formatter method to TaskManagerLocation and ArchivedTaskManagerLocation that prints in the form of "${hostname}:${port}" to align the string formatter used by REST API. 2. Highlight that the old host field will

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Yangze, Thanks for the input, totally agree with you, will take the advice. Best, Zhanghao Chen 发件人: Yangze Guo 发送时间: 2023年9月15日 17:26 收件人: dev@flink.apache.org 主题: Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Thanks for driving this, Zhanghao. +1 for the overall proposal. Some cents from my side: 1. Since most of the rest api get the location from TaskManagerLocation, we can align the string formatter in this class. E.g. add something like toHumanRealableString to this class. 2. From my

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Jing, Thanks for the suggestion. Endpoint is indeed a more professional word in the networking world but I think location is more suited here for two reasons: 1. The term here is for uniquely identifying the TaskManager where the task is deployed while providing the host machine info as

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Zhanghao, Thanks for bringing this to our attention. It is a good proposal to improve data consistency. Speaking of naming conventions of choosing location over host, how about "endpoint" with the following thoughts: 1. endpoint is a more professional word than location in the network

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi, Zhanghao Since the meaning of "host" is not aligned, it seems good for me to remove it in the future release. Best, Weihua On Mon, Sep 11, 2023 at 11:48 AM Chen Zhanghao wrote: > Hi Fan Rui, > > Thanks for clarifying the definition of "public interfaces", that helps a > lot! > > Best, >

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Fan Rui, Thanks for clarifying the definition of "public interfaces", that helps a lot! Best, Zhanghao Chen 发件人: Rui Fan <1996fan...@gmail.com> 发送时间: 2023年9月11日 11:18 收件人: dev@flink.apache.org 主题: Re: [DISCUSS] FLIP-363: Unify the Representation of

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Weihua, Thanks for the suggestion on keeping the host field. However, I think the location field can serve the needs for finding host-aggregative tasks as well and I'm not sure if a separate host field is still needed. The fields in REST API are mainly used under two scenarios, UI & code

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Thanks Zhanghao driving this FLIP, adding the port in Web UI seems good to me. Hi Shammon and Zhanghao, I would like to clarify the difference between Public Interfaces in FLIP and @Public in code. As I understand, the `Public Interfaces in FLIP` means these changes will be used in user side,

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi, Zhanghao Thanks for bringing this proposal. I have a concern: I prefer to keep the "host" field and add a "location" field in future versions. Consider a scenario where a machine (host) with multiple TaskManagers has poor processing performance due to some problems. By using a host field

回复: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Shammon, I think all REST API response messages (e.g. SubtaskExecutionAttemptDetailsInfo) should be considered as part of the public APIs and therefore be marked as @Public. It is true though none of them are marked as @public yet. Maybe we should do that. ccing

Re: [DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Thanks Zhanghao for initialing this discussion, I have just one comment: I checked the classes `SubtasksAllAccumulatorsHandler`, `SubtasksTimesHandler`, `SubtaskCurrentAttemptDetailsHandler`, `JobVertexTaskManagersHandler` and `JobExceptionsHandler` you mentioned in `Public Interfaces` and they

[DISCUSS] FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI

Hi Devs, I would like to start a discussion on FLIP-363: Unify the Representation of TaskManager Location in REST API and Web UI [1]. The TaskManager location of subtasks is important for identifying TM-related problems. There are a number of places in REST API and Web UI where TaskManager