Thanks for the clarification, I just read the KIP. Got it now :-)
Regards,
Jeff
On Mon, Jun 26, 2017 at 10:01 AM, larry mccay <[email protected]> wrote:
> Hi Jeff -
>
> The port-mapping is not actually on the service dispatch side but instead
> client facing.
> So, instead of requiring: https://localhost:8443/
> gateway/sandbox/webhdfs/v1/?op=LISTSTATUS to access webhdfs through the
> sandbox topology we can dedicate a new port to listen for requests that is
> dedicated to the sandbox topology. This will allow:
> https://localhost:8444/webhdfs/v1/?op=LISTSTATUS to be used instead.
>
> You can read more about port-mapping in the KIP-6 [1]
>
> The point of this thread is to investigate the fact that the relative URLs
> that are used in UIs will automatically be going back to the same host:port
> as was used in the initial request that there is no reason to add the
> additional prefix of "gateway/sandbox" to the relative URL and how we might
> consider forcing port-mapping for UI-only topologies and simplify the
> rewrite rules for UIs.
>
> Hope that makes sense...
>
> thanks,
>
> --larry
>
>
> 1. https://cwiki.apache.org/confluence/display/KNOX/KIP-6+
> Topology+Port+Mapping
>
> On Mon, Jun 26, 2017 at 12:46 PM, Jeffrey Rodriguez <[email protected]>
> wrote:
>
>> All,
>> The information about hosts/ports is known to Ambari and topology
>> gets that information from Ambari Stack params calls to cluster components
>> variables. e.g. When we enable HA, we get all namenodes hosts, ports and
>> whether SSL is on so we can setup scheme, host and port. Not only that but
>> through the ports can be change.
>> So there is a lot of information for UIs and REST hosts/ports and whether
>> we support HA or not.
>> Would the new port mapping, generate the scheme, port, HA enable/not,
>> host(s)? I can see if this information would be generated by call from Knox
>> stack and be part of the configuration then we would not need the topology.
>> One requirement would also be that when cluster configuration would
>> change the port mapping would need to be updated too. So maybe cluster
>> services, WEBHDFS for example, if we set HA and have a set of namenodes,
>> ports, scheme, when the service starts it would update knox data (plain
>> file or json).
>>
>> Regards,
>> Jeff Rodriguez
>>
>>
>> On Mon, Jun 26, 2017 at 9:11 AM, larry mccay <[email protected]> wrote:
>>
>>> All -
>>>
>>> It is becoming more and more clear that UI proxying is going to continue
>>> to be a moving target and we need to determine how to simplify the
>>> authoring and maintenance of UI rewrite rules.
>>>
>>> While I haven't put a lot of thought around it or even POC'd it yet, I
>>> am thinking about the possibility of leveraging the new port-mapping
>>> feature for UIs.
>>>
>>> This may at least be able to eliminate the need for the
>>> "gateway/topology" patch prefix by the fact that we dedicate specific ports
>>> to specific topologies.
>>>
>>> The downside of this is that it contradicts one of our early tenants of
>>> enabling deployments to have a single host:port available to access all of
>>> the REST API resources that they require.
>>>
>>> We may be able to justify that UIs be on a separate port however.
>>>
>>> Then we will also need to deal with backward compatibility issues for
>>> deployments that are currently using the existing service definitions - we
>>> may be able to accommodate this using the versioning built into service
>>> defs.
>>>
>>> Anyway, I just thought that I would start a discussion on this and see
>>> what folks have to say.
>>>
>>> Thoughts?
>>>
>>> --larry
>>>
>>
>>
>
