[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
]
Kevin Risden updated KNOX-1153:
---
Fix Version/s: (was: 0.15.0)
1.1.0
> 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: 1.1.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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become discrete service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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)
[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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become discrete service-level params:
{code:java}
HIVE
"
"
{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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become discrete service-level params:
{code:java}
HIVE
"
"
{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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become discrete service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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)
[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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become discrete service-level params:
{code:java}
HIVE
"
"
{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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become service-level params:
{code:java}
HIVE
"
"
{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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become discrete service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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)
[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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become service-level params:
{code:java}
HIVE
"
"
{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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become service-level params:
{code:java}
HIVE
"
"
{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.
> 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
> 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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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
(v6.4.14#64029)
[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:
---
Issue Type: Improvement (was: Bug)
> 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
> 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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become service-level params:
{code:java}
HIVE
"
"
{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.
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}
ha
HaProvider
true
...
HIVE
{code}
The HIVE param value would become service-level params:
{code:java}
HIVE
"
"
{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.
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 configure Knox to interact with the HA-enabled
service.
> Dynamic HaProvider Configuration for Generated Topologies
> -
>
> Key: KNOX-1153
> URL: https://issues.apache.org/jira/browse/KNOX-1153
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.14.0
>Reporter: Phil Zampino
>Assignee: Phil Zampino
> 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}
>
> ha
> HaProvider
> true
>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"
> />
>
>
> ...
>
> HIVE
>
> {code}
> The HIVE param value would become service-level params:
> {code:java}
>
> HIVE
>
> "
> "
>value="machine1:2181,machine2:2181,machine3:2181"/>
>
>
> {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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
