Page History

...

In order to simplify what management UI's need to manage, we should support a much simpler descriptor that contains what is needed to generate an actual topology file at deployment time (see item #3 #1 from the Motivation section).

...

• Service discovery type
  An identifier indicating which type of discovery to apply (e.g., Ambari, etc...)
• Service discovery address
  The associated service registry address
• A provider configuration reference (a unique name, filename, etc...)
  A unique name mapped to a set of provider configurationsconfigurations  (see item #3 from the Motivation section)
• A list of services to be exposed through Knox (with optional URL value)
• A list of UIs to be proxied by Knox (per KIP-9)

...

It would also be helpful to provide a means by which these descriptors can be easily published to the correct location in a znode.

4. Service Discovery

Item #2 from the Motivation section addresses the usability issues associated with having to manually edit a topology descriptor to specify the various service URLs in a cluster.
Beyond the obvious tedium associated with this task, there is real potential for human error, especially when multiple Knox instances are involved. The proposed solution to this
is automated service discovery, by which the URLs for the services to be exposed are discovered and added to a topology.

In order to transform the a Simplified Topology Descriptor into a full topology, we need some source for the relevant details and metadata. Knox is often deployed in clusters
with Ambari and ZooKeeper also deployed, and both contain some level of the needed metadata about the service URLs wtihin the cluster.

...