THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The simplest example of one such mapping involves a service component for which there is a single configuration property which specifies the complete URL
Code Block | ||
---|---|---|
| ||
<!-- This is the service mapping declaration. The name must match what is specified as a Knox topology service role --> <service name="OOZIE"> <!-- This is the URL pattern with palceholder(s) for values provided by properties --> <url-pattern>{OOZIE_URL}</url-pattern> <properties> <!-- This is a property, which in this simple case, matches a template placeholder --> <property name="OOZIE_URL"> <!-- This is the component whose configuration will be used to lookup the value of the subsequent config property name --> <component>OOZIE_SERVER</component> <!-- This is the name of the component config property whose value should be assigned to the OOZIE_URL value --> <config-property>oozie.base.url</config-property> </property> </properties> </service> |
...
If Apache SOLR weren't supported, then it could be added by creating the {GATEWAY_HOME}/conf/ambari-discovery-url-mappings.xml file with the following content:
Code Block | ||
---|---|---|
| ||
<?xml version="1.0" encoding="utf-8"?> <service-discovery-url-mappings> <service name="SOLR"> <url-pattern>http://{HOST}:{PORT}</url-pattern> <properties> <property name="HOST"> <component>INFRA_SOLR</component> <hostname/> </property> <property name="PORT"> <component>INFRA_SOLR</component> <config-property>infra_solr_port</config-property> </property> </properties> </service> </service-discovery-url-mappings> |
...