[
https://issues.apache.org/jira/browse/KNOX-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Zampino updated KNOX-1153:
-------------------------------
Description:
With the ability to share provider configuration across multiple topologies, it
would be good if the service-specific HA Provider configuration could be pushed
down into the service elements themselves, possibly with more generic (i.e.,
global) configuration specified at the provider level.
For instance, rather than
{code:java}
<provider>
<role>ha</role>
<name>HaProvider</name>
<enabled>true</enabled>
<param name="HIVE"
value="maxFailoverAttempts=3;failoverSleep=1000;enabled=true;zookeeperEnsemble=c6801.ambari.apache.org:2181,c6802.ambari.apache.org:2181,c6803.ambari.apache.org:2181;zookeeperNamespace=hiveserver2"
/>
</provider>
</gateway>
...
<service>
<role>HIVE</role>
</service>
{code}
The HIVE param value would become discrete service-level params:
{code:java}
<service>
<role>HIVE</role>
<param name="ha" value="true"/>
<param name="maxFailoverAttempts" value="3"/>"
<param name="failoverSleep" value="1000"/>"
<param name="zookeeperEnsemble"
value="machine1:2181,machine2:2181,machine3:2181"/>
<param name="zookeeperNamespace" value="hiveserver2"/>
</service>
{code}
This has the potential to increase the share-ability of provider
configurations. It also makes more sense for the service-specific details to be
co-located with the services themselves. An additional benefit is that the
cluster discovery information includes the ZooKeeper details for most services,
so those details can optionally be provided automatically in generated
topologies.
Furthermore, it should be possible to determine whether or not HA is configured
for a service, in which case, topology generation could use the cluster
discovery information to automatically enable Knox to interact with the service
in an HA manner.
[https://cwiki.apache.org/confluence/display/KNOX/Dynamic+HA+Provider+Configuration]
was:
With the ability to share provider configuration across multiple topologies, it
would be good if the service-specific HA Provider configuration could be pushed
down into the service elements themselves, possibly with more generic (i.e.,
global) configuration specified at the provider level.
For instance, rather than
{code:java}
<provider>
<role>ha</role>
<name>HaProvider</name>
<enabled>true</enabled>
<param name="HIVE"
value="maxFailoverAttempts=3;failoverSleep=1000;enabled=true;zookeeperEnsemble=c6801.ambari.apache.org:2181,c6802.ambari.apache.org:2181,c6803.ambari.apache.org:2181;zookeeperNamespace=hiveserver2"
/>
</provider>
</gateway>
...
<service>
<role>HIVE</role>
</service>
{code}
The HIVE param value would become service-level params:
{code:java}
<service>
<role>HIVE</role>
<param name="ha" value="true"/>
<param name="maxFailoverAttempts" value="3"/>"
<param name="failoverSleep" value="1000"/>"
<param name="zookeeperEnsemble"
value="machine1:2181,machine2:2181,machine3:2181"/>
<param name="zookeeperNamespace" value="hiveserver2"/>
</service>
{code}
This has the potential to increase the share-ability of provider
configurations. It also makes more sense for the service-specific details to be
co-located with the services themselves. An additional benefit is that the
cluster discovery information includes the ZooKeeper details for most services,
so those details can optionally be provided automatically in generated
topologies.
Furthermore, it should be possible to determine whether or not HA is configured
for a service, in which case, topology generation could use the cluster
discovery information to automatically enable Knox to interact with the service
in an HA manner.
https://cwiki.apache.org/confluence/display/KNOX/Dynamic+HA+Provider+Configuration
> Dynamic HaProvider Configuration for Generated Topologies
> ---------------------------------------------------------
>
> Key: KNOX-1153
> URL: https://issues.apache.org/jira/browse/KNOX-1153
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 0.14.0
> Reporter: Phil Zampino
> Assignee: Phil Zampino
> Priority: Major
> Fix For: 0.15.0
>
>
> With the ability to share provider configuration across multiple topologies,
> it would be good if the service-specific HA Provider configuration could be
> pushed down into the service elements themselves, possibly with more generic
> (i.e., global) configuration specified at the provider level.
> For instance, rather than
> {code:java}
> <provider>
> <role>ha</role>
> <name>HaProvider</name>
> <enabled>true</enabled>
> <param name="HIVE"
> value="maxFailoverAttempts=3;failoverSleep=1000;enabled=true;zookeeperEnsemble=c6801.ambari.apache.org:2181,c6802.ambari.apache.org:2181,c6803.ambari.apache.org:2181;zookeeperNamespace=hiveserver2"
> />
> </provider>
> </gateway>
> ...
> <service>
> <role>HIVE</role>
> </service>
> {code}
> The HIVE param value would become discrete service-level params:
> {code:java}
> <service>
> <role>HIVE</role>
> <param name="ha" value="true"/>
> <param name="maxFailoverAttempts" value="3"/>"
> <param name="failoverSleep" value="1000"/>"
> <param name="zookeeperEnsemble"
> value="machine1:2181,machine2:2181,machine3:2181"/>
> <param name="zookeeperNamespace" value="hiveserver2"/>
> </service>
> {code}
> This has the potential to increase the share-ability of provider
> configurations. It also makes more sense for the service-specific details to
> be co-located with the services themselves. An additional benefit is that the
> cluster discovery information includes the ZooKeeper details for most
> services, so those details can optionally be provided automatically in
> generated topologies.
> Furthermore, it should be possible to determine whether or not HA is
> configured for a service, in which case, topology generation could use the
> cluster discovery information to automatically enable Knox to interact with
> the service in an HA manner.
> [https://cwiki.apache.org/confluence/display/KNOX/Dynamic+HA+Provider+Configuration]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
