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 <[email protected]> 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 >
