[jira] [Comment Edited] (FLINK-9179) Deduplicate WebOptions.PORT and RestOptions.REST_PORT

["Chesnay Schepler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-9179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458425#comment-16458425 ] 

Chesnay Schepler edited comment on FLINK-9179 at 4/30/18 9:27 AM:
------------------------------------------------------------------

It's _probably_ possible to do, but I'm wondering whether users actually gain anything.

The server-side is doable; move the StaticFileServerHandler into a separate RestEndpoint and add a bit of plumbing to support 2 endpoints in the dispatcher.
The client-side however is problematic as IIRC the rest calls implicitly go against the same port that the UI is running on. I don't know how we could dynamically set this to a different port, outside of injecting it into {{index.js}} on the fly or adding a separate handler on the UI port that returns the REST port, which architecturally speaking seems funky.

The only use-case I could see is to make it easier to restrict access to the REST API while retaining a functioning WebUI. This will become more important as we extend the REST API with more control functions.
But I don't know enough about how one would implement this to make a definitive statement as to whether this is actually the case. The problem I see is that one would have to enumerate all paths to allow/restrict which is error-prone and hard to maintain, whereas a separate port is easy to detect. But then how is the WebUI still allowed to access everything it needs?

We are in bad spot here; if we don't change the keys the transition to 1.5 will be bumpy, but if we change them we can't reverse it easily.




was (Author: zentol):
It's _probably_ possible to do, but I'm wondering whether users actually gain anything.

The server-side is doable; move the StaticFileServerHandler into a separate RestEndpoint and add a bit of plumbing to support 2 endpoints in the dispatcher.
The client-side however is problematic as IIRC the rest calls implicitly go against the same port that the UI is running on. I don't know how we could dynamically set this to a different port, outside of injecting it into {{index.js}} on the fly.

The only use-case I could see is to make it easier to restrict access to the REST API while retaining a functioning WebUI. This will become more important as we extend the REST API with more control functions.
But I don't know enough about how one would implement this to make a definitive statement as to whether this is actually the case. The problem I see is that one would have to enumerate all paths to allow/restrict which is error-prone and hard to maintain, whereas a separate port is easy to detect. But then how is the WebUI still allowed to access everything it needs?

We are in bad spot here; if we don't change the keys the transition to 1.5 will be bumpy, but if we change them we can't reverse it easily.



> Deduplicate WebOptions.PORT and RestOptions.REST_PORT
> -----------------------------------------------------
>
>                 Key: FLINK-9179
>                 URL: https://issues.apache.org/jira/browse/FLINK-9179
>             Project: Flink
>          Issue Type: Improvement
>          Components: Configuration, REST, Webfrontend
>    Affects Versions: 1.5.0
>            Reporter: Chesnay Schepler
>            Assignee: mingleizhang
>            Priority: Blocker
>             Fix For: 1.5.0
>
>
> In the past {{WebOptions.PORT}} was used to configure the port on which the WebUI listens on. With the rework of the REST API we added a new configuration key {{RestOptions.REST_PORT}} to specify on which port the REST API listens on.
> Effectively these 2 options control the same thing, with the rest option being broader and also applicable to components with a REST API but no WebUI.
> I suggest to deprecate WebOptions.PORT, and add a deprecated key to {{RestOptions.REST_PORT}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)