You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by larry mccay <lm...@apache.org> on 2017/10/17 03:55:11 UTC
[KIP-9] Progress with Ambari UI as Example
All -
I have been working on trying to simplify the rewrite rules required for
proxying UIs, as is the goal of KIP-9 [1].
I started with the assumption of having specific topologies for each UI. In
order to not have to provide rewrite rules to add some artificial app path
element - such as 'ambari' - I have added a default path element to the
topology. Using this feature, a call to
https://localhost:8443/gateway/sandbox-ambari will result in the gateway
resolving it to https://localhost:8443/gateway/sandbox-ambari/ambari
internally but rendered URLs do not need to have that element.
Thus, we can remove all rewrite rules that merely add that path to the URL.
It seems that this approach does work to help make the rewrite rules more
generic and I think that the progress is worth pursuing the rest of KIP-9
as well. I thought that I would share the results with you beforehand
however.
I was hoping to reduce the number of rules more substantially than it does.
At the same time, this approach no longer requires a rewrite rule for every
single file that may be linked in an application and its associated
framework.
It allows us to move from:
<rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorcss">
<rewrite
template="{$frontend[path]}/ambari/stylesheets/vendor.css"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/appcss">
<rewrite template="{$frontend[path]}/ambari/stylesheets/app.css"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorjs">
<rewrite template="{$frontend[path]}/ambari/javascripts/vendor.js"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/appjs">
<rewrite template="{$frontend[path]}/ambari/javascripts/app.js"/>
</rule>
to:
<rule dir="OUT" name="AMBARIUI/ambari/outbound/css">
<rewrite template="{$frontend[path]}/stylesheets/{**}"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/js">
<rewrite template="{$frontend[path]}/javascripts/{**}"/>
</rule>
The elimination of the file specific rules leads to a much less brittle
service definition and hopefully fewer breakages from version to version.
Overall, at this point, it seems that the rewrite.xml for ambariui can be
reduced by about 20 lines of XML. Not a huge simplification but the ability
to wildcard resources in directories can be huge in terms of new files,
images, etc that may be added to existing directories.
Here is the reduced ambariui rewrite.xml:
<rules>
<rule dir="IN" name="AMBARIUI/ambari/inbound/root"
pattern="*://*:*/**/ambari/">
<rewrite template="{$serviceUrl[AMBARIUI]}/"/>
</rule>
<rule dir="IN" name="AMBARIUI/ambari/inbound/path"
pattern="*://*:*/**/ambari/{**}">
<rewrite template="{$serviceUrl[AMBARIUI]}/{**}"/>
</rule>
<rule dir="IN" name="AMBARIUI/ambari/inbound/query"
pattern="*://*:*/**/ambari/{**}?{**}">
<rewrite template="{$serviceUrl[AMBARIUI]}/{**}?{**}"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/sitepath">
<rewrite template="{$frontend[path]}/"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/extrapath">
<rewrite template="{$frontend[path]}/api/v1"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/logohref">
<rewrite template="#/main/dashboard"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/img" pattern="/img/{**}">
<rewrite template="{$frontend[path]}/img/{**}"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/css">
<rewrite template="{$frontend[path]}/stylesheets/{**}"/>
</rule>
<rule dir="OUT" name="AMBARIUI/ambari/outbound/js">
<rewrite template="{$frontend[path]}/javascripts/{**}"/>
</rule>
<filter name="AMBARIUI/ambari/outbound/proxyroot">
<content type="*/x-javascript">
<apply path="\{proxy_root\}"
rule="AMBARIUI/ambari/outbound/sitepath"/>
</content>
<content type="application/javascript">
<apply path="\{proxy_root\}"
rule="AMBARIUI/ambari/outbound/sitepath"/>
</content>
</filter>
<!-- filter to rewrite api prefix defined in .js from root -->
<!-- e.g. /api/v1 -->
<filter name="AMBARIUI/ambari/outbound/apiendpoint">
<content type="*/x-javascript">
<apply path="/api/v1"
rule="AMBARIUI/ambari/outbound/extrapath"/>
</content>
<content type="application/javascript">
<apply path="/api/v1"
rule="AMBARIUI/ambari/outbound/extrapath"/>
</content>
</filter>
<filter name="AMBARIUI/ambari/outbound/apiendpoint/html">
<content type="text/html">
<apply path="/api/v1"
rule="AMBARIUI/ambari/outbound/extrapath"/>
</content>
</filter>
<filter name="AMBARIUI/ambari/outbound/apiendpoint/noroot">
<content type="*/x-javascript">
<apply path="api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/>
</content>
<content type="application/javascript">
<apply path="api/v1" rule="AMBARIUI/ambari/outbound/extrapath"/>
</content>
</filter>
<filter name="AMBARIUI/ambari/outbound/links">
<content type="*/x-javascript">
<apply path="/api/v1"
rule="AMBARIUI/ambari/outbound/extrapath"/>
<apply path="\{proxy_root\}"
rule="AMBARIUI/ambari/outbound/sitepath"/>
<apply path="/#/main/dashboard"
rule="AMBARIUI/ambari/outbound/logohref"/>
</content>
<content type="application/javascript">
<apply path="/api/v1"
rule="AMBARIUI/ambari/outbound/extrapath"/>
<apply path="\{proxy_root\}"
rule="AMBARIUI/ambari/outbound/sitepath"/>
<apply path="/#/main/dashboard"
rule="AMBARIUI/ambari/outbound/logohref"/>
</content>
<content type="*/html">
</content>
</filter>
<filter name="AMBARIUI/ambari/outbound/mainpage">
<content type="*/html">
<apply path="stylesheets/{**}.css"
rule="AMBARIUI/ambari/outbound/css" />
<apply path="javascripts/{**}.js"
rule="AMBARIUI/ambari/outbound/js" />
</content>
</filter>
</rules>
Feel free to compare to the existing rewrite.xml in
{GATEWAY_HOME}/data/services/ambariui/2.2.0/rewrite.xml
Perhaps other UI service definitions will be simplified by a more
impressive amount.
I am a bit concerned about whether we can think through exactly how to
migrate existing service definitions and deployments in a backward
compatible way for the 0.14.0 release timeframe.
* We could add a new version of the service definitions and require old
deployments to be changed to specify the old version.
* We could add new service definitions for each UI which would assume this
deployment pattern and continue to support the existing way as well.
** we could also have an 0.14.0 release that continues to support both as
described here but in a separate 1.0.0 release we stop support for the old
patterns for UI proxying. Don't particularly like this but it may be
cleanest approach.
* We could continue to use the service element instead of introducing a new
UI element and discover from service definition whether it is a UI and
handle it as a UI element as described in KIP-9.
** this would likely require each topology to be redeployed on upgrade and
the generation of new topologies based on the service def metadata.
Anyway, the above coming together in the next couple of weeks concerns me
and I am wondering if it should be pushed out to 0.15.0/1.1.0 release.
Please feel free to share any thoughts, concerns or ideas that you may have
on this effort.
thanks,
--larry
1.
https://cwiki.apache.org/confluence/display/KNOX/KIP-9+Simplified+UI+Rewrite+Rules+and+Proxying
Re: [KIP-9] Progress with Ambari UI as Example
Posted by Sandeep More <mo...@gmail.com>.
Hello Larry,
Thanks for sharing the details, this is exciting and would fix / prevent a
lot of issues we have with Rewrite rules.
Given the concerns you raised about backwards compatibility for upgrade I
am a bit concerned about this going into 0.14.0 too and would be in favor
or pushing it out to 0.15.0 / 1.0.0 if no one needs it in 0.14.0 release.
Best,
Sandeep
On Mon, Oct 16, 2017 at 11:55 PM, larry mccay <lm...@apache.org> wrote:
> All -
>
> I have been working on trying to simplify the rewrite rules required for
> proxying UIs, as is the goal of KIP-9 [1].
>
> I started with the assumption of having specific topologies for each UI. In
> order to not have to provide rewrite rules to add some artificial app path
> element - such as 'ambari' - I have added a default path element to the
> topology. Using this feature, a call to
> https://localhost:8443/gateway/sandbox-ambari will result in the gateway
> resolving it to https://localhost:8443/gateway/sandbox-ambari/ambari
> internally but rendered URLs do not need to have that element.
>
> Thus, we can remove all rewrite rules that merely add that path to the URL.
>
> It seems that this approach does work to help make the rewrite rules more
> generic and I think that the progress is worth pursuing the rest of KIP-9
> as well. I thought that I would share the results with you beforehand
> however.
>
> I was hoping to reduce the number of rules more substantially than it does.
> At the same time, this approach no longer requires a rewrite rule for every
> single file that may be linked in an application and its associated
> framework.
>
> It allows us to move from:
>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorcss">
> <rewrite
> template="{$frontend[path]}/ambari/stylesheets/vendor.css"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/appcss">
> <rewrite template="{$frontend[path]}/ambari/stylesheets/app.css"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/vendorjs">
> <rewrite template="{$frontend[path]}/
> ambari/javascripts/vendor.js"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/appjs">
> <rewrite template="{$frontend[path]}/ambari/javascripts/app.js"/>
> </rule>
>
> to:
>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/css">
> <rewrite template="{$frontend[path]}/stylesheets/{**}"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/js">
> <rewrite template="{$frontend[path]}/javascripts/{**}"/>
> </rule>
>
> The elimination of the file specific rules leads to a much less brittle
> service definition and hopefully fewer breakages from version to version.
>
> Overall, at this point, it seems that the rewrite.xml for ambariui can be
> reduced by about 20 lines of XML. Not a huge simplification but the ability
> to wildcard resources in directories can be huge in terms of new files,
> images, etc that may be added to existing directories.
>
> Here is the reduced ambariui rewrite.xml:
>
> <rules>
> <rule dir="IN" name="AMBARIUI/ambari/inbound/root"
> pattern="*://*:*/**/ambari/">
> <rewrite template="{$serviceUrl[AMBARIUI]}/"/>
> </rule>
> <rule dir="IN" name="AMBARIUI/ambari/inbound/path"
> pattern="*://*:*/**/ambari/{**}">
> <rewrite template="{$serviceUrl[AMBARIUI]}/{**}"/>
> </rule>
> <rule dir="IN" name="AMBARIUI/ambari/inbound/query"
> pattern="*://*:*/**/ambari/{**}?{**}">
> <rewrite template="{$serviceUrl[AMBARIUI]}/{**}?{**}"/>
> </rule>
>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/sitepath">
> <rewrite template="{$frontend[path]}/"/>
> </rule>
>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/extrapath">
> <rewrite template="{$frontend[path]}/api/v1"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/logohref">
> <rewrite template="#/main/dashboard"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/img"
> pattern="/img/{**}">
> <rewrite template="{$frontend[path]}/img/{**}"/>
> </rule>
>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/css">
> <rewrite template="{$frontend[path]}/stylesheets/{**}"/>
> </rule>
> <rule dir="OUT" name="AMBARIUI/ambari/outbound/js">
> <rewrite template="{$frontend[path]}/javascripts/{**}"/>
> </rule>
>
> <filter name="AMBARIUI/ambari/outbound/proxyroot">
> <content type="*/x-javascript">
> <apply path="\{proxy_root\}"
> rule="AMBARIUI/ambari/outbound/sitepath"/>
> </content>
> <content type="application/javascript">
> <apply path="\{proxy_root\}"
> rule="AMBARIUI/ambari/outbound/sitepath"/>
> </content>
> </filter>
>
> <!-- filter to rewrite api prefix defined in .js from root -->
> <!-- e.g. /api/v1 -->
> <filter name="AMBARIUI/ambari/outbound/apiendpoint">
> <content type="*/x-javascript">
> <apply path="/api/v1"
> rule="AMBARIUI/ambari/outbound/extrapath"/>
> </content>
> <content type="application/javascript">
> <apply path="/api/v1"
> rule="AMBARIUI/ambari/outbound/extrapath"/>
> </content>
> </filter>
>
> <filter name="AMBARIUI/ambari/outbound/apiendpoint/html">
> <content type="text/html">
> <apply path="/api/v1"
> rule="AMBARIUI/ambari/outbound/extrapath"/>
> </content>
> </filter>
>
> <filter name="AMBARIUI/ambari/outbound/apiendpoint/noroot">
> <content type="*/x-javascript">
> <apply path="api/v1" rule="AMBARIUI/ambari/
> outbound/extrapath"/>
> </content>
> <content type="application/javascript">
> <apply path="api/v1" rule="AMBARIUI/ambari/
> outbound/extrapath"/>
> </content>
> </filter>
>
> <filter name="AMBARIUI/ambari/outbound/links">
> <content type="*/x-javascript">
> <apply path="/api/v1"
> rule="AMBARIUI/ambari/outbound/extrapath"/>
> <apply path="\{proxy_root\}"
> rule="AMBARIUI/ambari/outbound/sitepath"/>
> <apply path="/#/main/dashboard"
> rule="AMBARIUI/ambari/outbound/logohref"/>
> </content>
> <content type="application/javascript">
> <apply path="/api/v1"
> rule="AMBARIUI/ambari/outbound/extrapath"/>
> <apply path="\{proxy_root\}"
> rule="AMBARIUI/ambari/outbound/sitepath"/>
> <apply path="/#/main/dashboard"
> rule="AMBARIUI/ambari/outbound/logohref"/>
> </content>
> <content type="*/html">
> </content>
> </filter>
> <filter name="AMBARIUI/ambari/outbound/mainpage">
> <content type="*/html">
> <apply path="stylesheets/{**}.css"
> rule="AMBARIUI/ambari/outbound/css" />
> <apply path="javascripts/{**}.js"
> rule="AMBARIUI/ambari/outbound/js" />
> </content>
> </filter>
> </rules>
>
> Feel free to compare to the existing rewrite.xml in
> {GATEWAY_HOME}/data/services/ambariui/2.2.0/rewrite.xml
>
> Perhaps other UI service definitions will be simplified by a more
> impressive amount.
>
> I am a bit concerned about whether we can think through exactly how to
> migrate existing service definitions and deployments in a backward
> compatible way for the 0.14.0 release timeframe.
>
> * We could add a new version of the service definitions and require old
> deployments to be changed to specify the old version.
> * We could add new service definitions for each UI which would assume this
> deployment pattern and continue to support the existing way as well.
> ** we could also have an 0.14.0 release that continues to support both as
> described here but in a separate 1.0.0 release we stop support for the old
> patterns for UI proxying. Don't particularly like this but it may be
> cleanest approach.
> * We could continue to use the service element instead of introducing a new
> UI element and discover from service definition whether it is a UI and
> handle it as a UI element as described in KIP-9.
> ** this would likely require each topology to be redeployed on upgrade and
> the generation of new topologies based on the service def metadata.
>
> Anyway, the above coming together in the next couple of weeks concerns me
> and I am wondering if it should be pushed out to 0.15.0/1.1.0 release.
>
> Please feel free to share any thoughts, concerns or ideas that you may have
> on this effort.
>
> thanks,
>
> --larry
>
> 1.
> https://cwiki.apache.org/confluence/display/KNOX/KIP-9+
> Simplified+UI+Rewrite+Rules+and+Proxying
>