Page History

...

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

...

Given that we will have a Service Discovery service that can integrate with Ambari as well as other sources of needed metadata, we should be able to start with a simplified topology descriptor.
Once the deployment machinery notices this descriptor, it can pull in the referenced provider configuration, iterate over each of the services, UIs, applications and lookup the details for each.
With the provider configuration and service details we can then generate a fully baked topology.

Let's assume a properties file for now:

Listing 1. sample.properties

provider.config=ProductionAD

service=NAMENODE,JOBTRACKER,WEBHDFS,WEBHCAT,OOZIE,WEBHBASE,HIVE,RESOURCEMANAGER,AMBARI

ui=AMBARIUI

From the example descriptors in the Simplified Topology Descriptors section, the resulting topology should include the provider configuration from the reference, and each service and UI (another KIP) with its respective URLsThe above properties file should result in the provider config being pulled in, each servicen and ui (an other KIP) with its appropriate URLs and details added and should results in something like the following:

Listing 2. sample.xml Sample Topology

...