You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Phil Zampino (JIRA)" <ji...@apache.org> on 2018/01/16 22:24:00 UTC

[jira] [Updated] (KNOX-1153) Dynamic HaProvider Configuration for Generated Topologies

     [ 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)