This sounds like a good improvement from a usability perspective. I agree that Knox must continue its support for direct topology (XML) definitions, but for those deployments where there is a service registry (e.g., Ambari, Zookeeper, Consul, etc...) with knowledge of the topology, the simplified config coupled with the service discovery could reduce topology (especially ServiceConnectivity) errors.
I also agree that consolidating provider configurations into named sets, which can be referenced from topology configurations, will be a good change, especially if there are commonly grouped providers employed by multiple topologies. Concerning the TODO sections, is your intention is that they contain the respective API facilities that will provide the information needed to populate a topology definition? - Phil On Fri, Aug 18, 2017 at 12:39 PM, larry mccay <[email protected]> wrote: > All - > > I have published an initial stab at a proposal for simplifying topology > management [1] - as I briefly mentioned on the 0.14.0 planning thread. > > There are a couple TODO sections that need some investigation for Ambari > API and Zookeeper Registry API as discovery plugins. > > Please give the KIP a read and let me know if it makes sense or if you > would like to take on specific pieces of this work. If you would like to > add other options or ideas, etc. > > I think that this will have a huge impact as usability improvements for > management of the gateway! > > thanks, > > --larry > > 1. > https://cwiki.apache.org/confluence/display/KNOX/KIP-8+ > Service+Discovery+and+Topology+Generation >
