THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
2. Simplified Topology Descriptor
Addressing item 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 from the Motivation section).
A , a simplified topology descriptor must allow the following details to be specified:
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
# Discovery info source
discovery-type : AMBARI
discovery-address : http://c6401.ambari.apache.org:8080
# Provider config reference, the contents of which will be
# included in (or referenced from) the resulting topology descriptor.
# The contents of this reference has a <gateway/> root, and
# contains <provider/> configurations.
provider-config-ref : ambari-cluster-policy.xml
# The cluster for which the service details should be discovered
cluster: mycluster
# The services to declare in the resulting topology descriptor,
# whose URLs will be discovered (unless a value is specified)
services:
- NAMENODE
- JOBTRACKER
- WEBHDFS
- WEBHCAT
- OOZIE
- WEBHBASE
- HIVE
- RESOURCEMANAGER
- AMBARI : http://c6401.ambari.apache.org:8080
- AMBARIUI : http://c6401.ambari.apache.org:8080
# UIs to be proxied through the resulting Knox topology (see KIP-9)
#uis:
# - AMBARIUI : http://c6401.ambari.apache.org:8080 |
3.Topology Generation
...
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 merely service and UI names and a reference to a named provider configuration. Once the deployment machinery finds the descriptor it can pull in the 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.
...