Author: pzampino
Date: Thu Jul 25 15:29:15 2019
New Revision: 1863741
URL: http://svn.apache.org/viewvc?rev=1863741&view=rev
Log:
Added info about new Cloudera Manager discovery support
Modified:
knox/trunk/books/1.3.0/config.md
knox/trunk/books/1.4.0/config.md
Modified: knox/trunk/books/1.3.0/config.md
URL:
http://svn.apache.org/viewvc/knox/trunk/books/1.3.0/config.md?rev=1863741&r1=1863740&r2=1863741&view=diff
==============================================================================
--- knox/trunk/books/1.3.0/config.md (original)
+++ knox/trunk/books/1.3.0/config.md Thu Jul 25 15:29:15 2019
@@ -506,17 +506,17 @@ Be sure to pay extra attention when shar
Simplified descriptors allow service URLs to be defined explicitly, just like
full topology descriptors. However, if URLs are
omitted for a service, Knox will attempt to discover that service's URLs from
the Hadoop cluster. Currently, this behavior is
-only supported for clusters managed by Ambari. In any case, the simplified
descriptors are much more concise than a full
-topology descriptor.
+only supported for clusters managed by Apache Ambari or Cloudera Manager. In
any case, the simplified descriptors are much more
+concise than a full topology descriptor.
*Descriptor Properties*
Property | Description
------------|-----------
-`discovery-type`|The discovery source type. (Currently, the only supported
type is `AMBARI`).
+`discovery-type`|The discovery source type. (Currently, the only supported
types are `AMBARI` and `ClouderaManager`).
`discovery-address`|The endpoint address for the discovery source.
-`discovery-user`|The username with permission to access the discovery source.
If omitted, then Knox will check for an alias named `ambari.discovery.user`,
and use its value if defined.
-`discovery-pwd-alias`|The alias of the password for the user with permission
to access the discovery source. If omitted, then Knox will check for an alias
named `ambari.discovery.password`, and use its value if defined.
+`discovery-user`|The username with permission to access the discovery source.
Optional, if the discovery type supports default credential aliases.
+`discovery-pwd-alias`|The alias of the password for the user with permission
to access the discovery source. Optional, if the discovery type supports
default credential aliases.
`provider-config-ref`|A reference to a provider configuration in
`{GATEWAY_HOME}/conf/shared-providers/`.
`cluster`|The name of the cluster from which the topology service endpoints
should be determined.
`services`|The collection of services to be included in the topology.
@@ -605,13 +605,23 @@ That being said, there is nothing preven
}
-Both of these examples illustrate the specification of credentials for the
interaction with Ambari. If no credentials are specified, then the default
-aliases are queried. Use of the default aliases is sufficient for scenarios
where topology discovery will only interact with a single Ambari instance.
-For multiple Ambari instances however, it's most likely that each will require
different sets of credentials. The discovery-user and discovery-pwd-alias
+Both of these examples illustrate the specification of credentials for the
interaction with the discovery source. If no credentials are specified, then
the default
+aliases are queried (if default aliases are supported for that discovery
type). Use of the default aliases is sufficient for scenarios where Knox will
only discover
+topology details from a single source.
+For multiple discovery sources however, it's most likely that each will
require different sets of credentials. The discovery-user and
discovery-pwd-alias
properties exist for this purpose. Note that whether using the default
credential aliases or specifying a custom password alias, these
[aliases must be defined](#Alias+creation) prior to any attempt to deploy a
topology using a simplified descriptor.
+##### Cluster Discovery Provider Extensions #####
+
+To support the ability to dynamically discover the endpoints for services
being proxied, Knox provides cluster discovery provider extensions for Apache
Ambari and Cloudera Manager.
+The Ambari support has been available since Knox 1.1.0, and limited support
for Cloudera Manager has been added in Knox 1.3.0.
+
+These extensions allow discovery sources of the respective types to be queried
for cluster details used to generate topologies from [simplified
descriptors](#Simplified+Descriptor+Files).
+The extension to be employed is specified on a per-descriptor basis, using the
`discovery-type` descriptor property.
+
+
##### Deployment Directories #####
Effecting topology changes is as simple as modifying files in two specific
directories.
@@ -642,7 +652,7 @@ Cloud Federation feature allows for a to
##### Cluster Configuration Monitoring #####
Another benefit gained through the use of simplified topology descriptors, and
the associated service discovery, is the ability to monitor clusters for
configuration changes.
-__Like service discovery, this is currently only available for clusters
managed by Ambari.__
+__This is currently only available for clusters managed by Ambari.__
The gateway can monitor Ambari cluster configurations, and respond to changes
by dynamically regenerating and redeploying the affected topologies.
The following properties in gateway-site.xml can be used to control this
behavior.
Modified: knox/trunk/books/1.4.0/config.md
URL:
http://svn.apache.org/viewvc/knox/trunk/books/1.4.0/config.md?rev=1863741&r1=1863740&r2=1863741&view=diff
==============================================================================
--- knox/trunk/books/1.4.0/config.md (original)
+++ knox/trunk/books/1.4.0/config.md Thu Jul 25 15:29:15 2019
@@ -506,17 +506,17 @@ Be sure to pay extra attention when shar
Simplified descriptors allow service URLs to be defined explicitly, just like
full topology descriptors. However, if URLs are
omitted for a service, Knox will attempt to discover that service's URLs from
the Hadoop cluster. Currently, this behavior is
-only supported for clusters managed by Ambari. In any case, the simplified
descriptors are much more concise than a full
-topology descriptor.
+only supported for clusters managed by Apache Ambari or Cloudera Manager. In
any case, the simplified descriptors are much more
+concise than a full topology descriptor.
*Descriptor Properties*
Property | Description
------------|-----------
-`discovery-type`|The discovery source type. (Currently, the only supported
type is `AMBARI`).
+`discovery-type`|The discovery source type. (Currently, the only supported
types are `AMBARI` and `ClouderaManager`).
`discovery-address`|The endpoint address for the discovery source.
-`discovery-user`|The username with permission to access the discovery source.
If omitted, then Knox will check for an alias named `ambari.discovery.user`,
and use its value if defined.
-`discovery-pwd-alias`|The alias of the password for the user with permission
to access the discovery source. If omitted, then Knox will check for an alias
named `ambari.discovery.password`, and use its value if defined.
+`discovery-user`|The username with permission to access the discovery source.
Optional, if the discovery type supports default credential aliases.
+`discovery-pwd-alias`|The alias of the password for the user with permission
to access the discovery source. Optional, if the discovery type supports
default credential aliases.
`provider-config-ref`|A reference to a provider configuration in
`{GATEWAY_HOME}/conf/shared-providers/`.
`cluster`|The name of the cluster from which the topology service endpoints
should be determined.
`services`|The collection of services to be included in the topology.
@@ -605,13 +605,23 @@ That being said, there is nothing preven
}
-Both of these examples illustrate the specification of credentials for the
interaction with Ambari. If no credentials are specified, then the default
-aliases are queried. Use of the default aliases is sufficient for scenarios
where topology discovery will only interact with a single Ambari instance.
-For multiple Ambari instances however, it's most likely that each will require
different sets of credentials. The discovery-user and discovery-pwd-alias
+Both of these examples illustrate the specification of credentials for the
interaction with the discovery source. If no credentials are specified, then
the default
+aliases are queried (if default aliases are supported for that discovery
type). Use of the default aliases is sufficient for scenarios where Knox will
only discover
+topology details from a single source.
+For multiple discovery sources however, it's most likely that each will
require different sets of credentials. The discovery-user and
discovery-pwd-alias
properties exist for this purpose. Note that whether using the default
credential aliases or specifying a custom password alias, these
[aliases must be defined](#Alias+creation) prior to any attempt to deploy a
topology using a simplified descriptor.
+##### Cluster Discovery Provider Extensions #####
+
+To support the ability to dynamically discover the endpoints for services
being proxied, Knox provides cluster discovery provider extensions for Apache
Ambari and Cloudera Manager.
+The Ambari support has been available since Knox 1.1.0, and limited support
for Cloudera Manager has been added in Knox 1.3.0.
+
+These extensions allow discovery sources of the respective types to be queried
for cluster details used to generate topologies from [simplified
descriptors](#Simplified+Descriptor+Files).
+The extension to be employed is specified on a per-descriptor basis, using the
`discovery-type` descriptor property.
+
+
##### Deployment Directories #####
Effecting topology changes is as simple as modifying files in two specific
directories.
@@ -642,7 +652,7 @@ Cloud Federation feature allows for a to
##### Cluster Configuration Monitoring #####
Another benefit gained through the use of simplified topology descriptors, and
the associated service discovery, is the ability to monitor clusters for
configuration changes.
-__Like service discovery, this is currently only available for clusters
managed by Ambari.__
+__This is currently only available for clusters managed by Ambari.__
The gateway can monitor Ambari cluster configurations, and respond to changes
by dynamically regenerating and redeploying the affected topologies.
The following properties in gateway-site.xml can be used to control this
behavior.
