[jira] [Created] (KNOX-1017) Add support for enabling "Strict-Transport-Security" header in knox reponses

[Latha Appanna (JIRA)]

Latha  Appanna created KNOX-1017:


 Summary:  Add support for enabling "Strict-Transport-Security" 
header in knox reponses 
 Key: KNOX-1017
 URL: https://issues.apache.org/jira/browse/KNOX-1017
 Project: Apache Knox
  Issue Type: Improvement
Reporter: Latha  Appanna
 Fix For: 0.14.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1013) Monitor Ambari for Topology changes

[Phil Zampino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Zampino updated KNOX-1013:
---
Description: 
Knox should provide the option to monitor an Ambari cluster for which it has 
deployed a topology, in order to notice configuration changes that affect the 
service URLs for that topology. Upon noticing such a change, Knox should 
respond by updating the deployed topology appropriately.


  was:
Knox should provide the option to monitor a cluster for which it has deployed a 
topology, in order to notice configuration changes that affect the service URLs 
for that topology. Upon noticing such a change, Knox should respond by updating 
the deployed topology appropriately.



> Monitor Ambari for Topology changes
> ---
>
> Key: KNOX-1013
> URL: https://issues.apache.org/jira/browse/KNOX-1013
> Project: Apache Knox
>  Issue Type: Sub-task
>  Components: Server
>Reporter: Phil Zampino
>
> Knox should provide the option to monitor an Ambari cluster for which it has 
> deployed a topology, in order to notice configuration changes that affect the 
> service URLs for that topology. Upon noticing such a change, Knox should 
> respond by updating the deployed topology appropriately.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KNOX-1015) ZooKeeper-Based Service Discovery

[Phil Zampino (JIRA)]

Phil Zampino created KNOX-1015:
--

 Summary: ZooKeeper-Based Service Discovery
 Key: KNOX-1015
 URL: https://issues.apache.org/jira/browse/KNOX-1015
 Project: Apache Knox
  Issue Type: Sub-task
  Components: Server
Reporter: Phil Zampino


Implement service discovery where ZooKeeper is the service registry.

Discover the appropriate URLs to declare in the Knox topology for the services 
specified in the simple topology descriptor.

Need to determine to what degree Hadoop services are registering their details 
in ZooKeeper, and may need to encourage them to do so or augment what they're 
already registering.

This must be named something less generic than "ZooKeeper" Service Discovery, 
since the implementation will depend on the structure of the data registered by 
the services, and will not be a general-purpose ZooKeeper service discovery 
mechanism.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KNOX-1014) Service Discovery and Topology Generation Framework

[Phil Zampino (JIRA)]

Phil Zampino created KNOX-1014:
--

 Summary: Service Discovery and Topology Generation Framework
 Key: KNOX-1014
 URL: https://issues.apache.org/jira/browse/KNOX-1014
 Project: Apache Knox
  Issue Type: Sub-task
  Components: Server
Reporter: Phil Zampino
Assignee: Phil Zampino


Implement the foundation for Service Discovery and Topology Generation.

* Define simple descriptor format (YAML, JSON, properties, etc...)
* Local simple descriptor discovery (re-use existing FileAlterationMonitor?)
* Ambari service discovery (REST API interactions and model construction)
** Configuration
*** How to plug-in discovery implementations (service loader?)
*** How to configure authentication (credentials/trust) with the service 
registries
* Topology assembly from simple descriptor and discovery details
* Topology deployment (something more than copy to the conf/topologies 
directory?)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KNOX-1012) ZooKeeper Monitor for Knox Topology Config Changes

[Phil Zampino (JIRA)]

Phil Zampino created KNOX-1012:
--

 Summary: ZooKeeper Monitor for Knox Topology Config Changes
 Key: KNOX-1012
 URL: https://issues.apache.org/jira/browse/KNOX-1012
 Project: Apache Knox
  Issue Type: Sub-task
Reporter: Phil Zampino


Knox should be able to monitor simple topology descriptors and provider 
configurations registered in ZooKeeper (per 
[KNOX-1010|http://issues.apache.org/jira/browse/KNOX-1006]), in order to notice 
when configurations have changed as compared with what has been deployed as a 
Knox topology.

* Simple descriptor changes
** Trigger re-generation/deployment of updated topology descriptor
** local (re-use existing FileAlterationMonitor?)
** remote
* Externalized provider config changes
** Trigger update of deployed topologies (runtime) that reference the modified 
provider config
** local (re-use existing FileAlterationMonitor?)
** remote



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-970) Add support for proxying NiFi

[Jeff Storck (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Storck updated KNOX-970:
-
Attachment: KNOX-970-PR-9.patch

> Add support for proxying NiFi
> -
>
> Key: KNOX-970
> URL: https://issues.apache.org/jira/browse/KNOX-970
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Reporter: Jeff Storck
> Fix For: 0.14.0
>
> Attachments: KNOX-970-PR-9.patch
>
>
> Apache NiFi hosts several known UIs/APIs at various context paths (/nifi, 
> /nifi-api, /nifi-docs, etc) and several dynamically discovered UIs/APIs 
> depending on individual installations/configurations of NiFi through multiple 
> component versions and custom NARs.
> Knox needs to be able to proxy to all of the available context paths in NiFi 
> without being configured for each one individually.
> The X-Forwarded-Context header set by Knox when proxying needs to include the 
> context path at which Knox is hosted (for example, /gateway/sandbox) and the 
> path at which the NiFi services are proxied (for example, nifi-web).  Using 
> this header with the extra context path information (from the given examples, 
> /gateway/sandbox/nifi-web), Knox needs to be able to rewrite URLs of incoming 
> requests to the root context of the web server hosted by NiFi.
> When proxying to a secured NiFi instance/cluster set up with multi-tenancy, 
> Knox also needs to set an additional header required by NiFi, 
> X-ProxiedEntitiesChain, which will contain the identity of the user making 
> the request to Knox.  If the header is present in an incoming request to 
> Knox, it must be able to take the DN from the SSL cert of the requesting 
> client (two-way SSL) and add it to the value received in the header.  The 
> requests made from Knox to NiFi must also be made with two-way SSL so that 
> NiFi can obtain the Knox server DN from its certificate.  The values present 
> in the X-ProxiedEntitiesChain will be used to authorize each identity 
> specified in the header of the proxied request before the operation will be 
> performed by NiFi.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KNOX-1010) Remote Discovery of Knox Topology Configuration

[Phil Zampino (JIRA)]

Phil Zampino created KNOX-1010:
--

 Summary: Remote Discovery of Knox Topology Configuration
 Key: KNOX-1010
 URL: https://issues.apache.org/jira/browse/KNOX-1010
 Project: Apache Knox
  Issue Type: Sub-task
  Components: Server
Reporter: Phil Zampino


To support HA deployments, Knox should be able to discover simple topology 
descriptors and provider configuration remotely.

- Define the ZooKeeper structure for remote config (simple desc, externalized 
provider) discovery
- Determine the best way to interact with ZooKeeper (REST, or some other client 
binding)
- Simple descriptor discovery
- External provider config discovery



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1009) Support Externalized Provider Configuration References From topology descriptors

[Phil Zampino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Zampino updated KNOX-1009:
---
Labels: kip-8  (was: )

> Support Externalized Provider Configuration References From topology 
> descriptors
> 
>
> Key: KNOX-1009
> URL: https://issues.apache.org/jira/browse/KNOX-1009
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Phil Zampino
>  Labels: kip-8
>
> Topology descriptors should support references to externalized provider 
> configuration to promote ease of sharing provider configurations across 
> cluster topologies and Knox instances.
> - Define external config content format (the same as today, but a separate 
> document with a  root)
> - Define external config reference format in topology.xml
> - Modify code to resolve external config references, and process them the 
> same as the current in-line  content
> - Includes determining how externalized provider config changes are 
> propagated to deployed topologies.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: KIP-8 Service Discovery and Topology Generation

[larry mccay]

I agree that named provider config should suffice. HA and AclsAuth
reference services within the topology and therfore will present a
challenge for reuse across topologies.

We'll need to figure that out.

On Aug 31, 2017 9:12 AM, "Philip Zampino"  wrote:

> Concerning the externalized provider configuration, the idea is to have
> sets of "named" (unique ID'd) config, which can be referenced by any Knox
> topology.
> So, you could have a single provider configuration that is applied (by
> reference) to all your cluster topologies, if that made sense for your
> deployment.
> This will allow a change to a single config (externalized provider config)
> to affect all the clusters topologies that reference it; rather than what
> is required today, which is to make the same change in every affected
> cluster topology config.
> Does that answer your question?
>
> I'll defer the HA question because I'm not yet familiar enough with it.
>
> Thanks for the feedback,
>Phil
>
> On Thu, Aug 31, 2017 at 3:42 AM, Krishna Pandey 
> wrote:
>
> > >
> > > As a result, I'm wondering if Knox should support provider
> configuration
> > > references in topology.xml, rather than having to duplicate it across
> > > descriptors.
> >
> >
> > +1 to Phil's remark above. Adding to that as Knox provides multi-cluster
> > support, can we have external provider config cluster-wise? Or we can
> > define multiple external provider config in single "global" provider
> config
> > file and refer them with some key?
> >
> > Also, when services are deployed in HA, we specify HaProvider and
> multiple
> > Service URLs in the topology. Will it make sense to use Load balancer IP
> > address / External URL for those services in topology instead of multiple
> > service URLs and using HaProvider?
> >
> > Thanks,
> > Krishna Pandey
> >
> > On Wed, Aug 30, 2017 at 10:05 PM, larry mccay  wrote:
> >
> > > Terrific, Phil!
> > >
> > >
> > > On Wed, Aug 30, 2017 at 11:03 AM, Philip Zampino 
> > > wrote:
> > >
> > > > After giving this KIP some thought, I would like to work on it. I've
> > > added
> > > > more detail to the wiki, and I'll create a JIRA for it.
> > > >
> > > > On Fri, Aug 25, 2017 at 10:03 AM, larry mccay 
> > wrote:
> > > >
> > > > > Wonderful details, Phil!
> > > > >
> > > > >
> > > > > On Fri, Aug 25, 2017 at 9:40 AM, Philip Zampino <
> pzamp...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks! I've added the Ambari API details to the wiki.
> > > > > >
> > > > > > On Fri, Aug 25, 2017 at 8:27 AM, larry mccay 
> > > > wrote:
> > > > > >
> > > > > > > HI Phil -
> > > > > > >
> > > > > > > Thank you for digging into this topic!
> > > > > > >
> > > > > > > I've added you as a contributor to the wiki and you should be
> > able
> > > to
> > > > > > edit
> > > > > > > the KIP now.
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > --larry
> > > > > > >
> > > > > > > On Thu, Aug 24, 2017 at 3:45 PM, Philip Zampino <
> > > pzamp...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I've put together a quick python POC targeting Ambari as the
> > > > > discovery
> > > > > > > > source, just to prove that we can indeed get the necessary
> > > details
> > > > > via
> > > > > > > > Ambari's REST API.
> > > > > > > > It generates a proper topology.xml descriptor based on a
> simple
> > > > > > > descriptor
> > > > > > > > (I chose YAML for this POC), which has a reference to what
> I've
> > > > > called
> > > > > > a
> > > > > > > > policy descriptor (the  portion of the topology
> > > > > descriptor).
> > > > > > > >
> > > > > > > > I am currently unable to update the KIP, but I can share the
> > REST
> > > > > APIs
> > > > > > > I've
> > > > > > > > employed if there is interest.
> > > > > > > >
> > > > > > > > As a result, I'm wondering if Knox should support provider
> > > > > > configuration
> > > > > > > > references in topology.xml, rather than having to duplicate
> it
> > > > across
> > > > > > > > descriptors.
> > > > > > > > So, instead of ... in each
> > > > > topology.xml,
> > > > > > > have
> > > > > > > > a single element that points to an external provider config
> > > (e.g.,
> > > > > > > > $GATEWAY_HOME/conf/policy/my-named-provider-
> > > > > > > > config.xml).
> > > > > > > > I've already externalized it for input to the POC, but I'm
> > still
> > > > > > copying
> > > > > > > > the contents into the resulting topology descriptor; I think
> it
> > > > would
> > > > > > be
> > > > > > > > better to copy only the reference.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > >  - Phil
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 18, 2017 at 1:55 PM, larry mccay <
> > lmc...@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Good to hear, Phil.
> > > > > > > > >
> > > > > > > > > Yes, I was looking to go back and add some of the API
> 

Re: KIP-8 Service Discovery and Topology Generation

[Philip Zampino]

Concerning the externalized provider configuration, the idea is to have
sets of "named" (unique ID'd) config, which can be referenced by any Knox
topology.
So, you could have a single provider configuration that is applied (by
reference) to all your cluster topologies, if that made sense for your
deployment.
This will allow a change to a single config (externalized provider config)
to affect all the clusters topologies that reference it; rather than what
is required today, which is to make the same change in every affected
cluster topology config.
Does that answer your question?

I'll defer the HA question because I'm not yet familiar enough with it.

Thanks for the feedback,
   Phil

On Thu, Aug 31, 2017 at 3:42 AM, Krishna Pandey 
wrote:

> >
> > As a result, I'm wondering if Knox should support provider configuration
> > references in topology.xml, rather than having to duplicate it across
> > descriptors.
>
>
> +1 to Phil's remark above. Adding to that as Knox provides multi-cluster
> support, can we have external provider config cluster-wise? Or we can
> define multiple external provider config in single "global" provider config
> file and refer them with some key?
>
> Also, when services are deployed in HA, we specify HaProvider and multiple
> Service URLs in the topology. Will it make sense to use Load balancer IP
> address / External URL for those services in topology instead of multiple
> service URLs and using HaProvider?
>
> Thanks,
> Krishna Pandey
>
> On Wed, Aug 30, 2017 at 10:05 PM, larry mccay  wrote:
>
> > Terrific, Phil!
> >
> >
> > On Wed, Aug 30, 2017 at 11:03 AM, Philip Zampino 
> > wrote:
> >
> > > After giving this KIP some thought, I would like to work on it. I've
> > added
> > > more detail to the wiki, and I'll create a JIRA for it.
> > >
> > > On Fri, Aug 25, 2017 at 10:03 AM, larry mccay 
> wrote:
> > >
> > > > Wonderful details, Phil!
> > > >
> > > >
> > > > On Fri, Aug 25, 2017 at 9:40 AM, Philip Zampino 
> > > > wrote:
> > > >
> > > > > Thanks! I've added the Ambari API details to the wiki.
> > > > >
> > > > > On Fri, Aug 25, 2017 at 8:27 AM, larry mccay 
> > > wrote:
> > > > >
> > > > > > HI Phil -
> > > > > >
> > > > > > Thank you for digging into this topic!
> > > > > >
> > > > > > I've added you as a contributor to the wiki and you should be
> able
> > to
> > > > > edit
> > > > > > the KIP now.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > --larry
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 3:45 PM, Philip Zampino <
> > pzamp...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I've put together a quick python POC targeting Ambari as the
> > > > discovery
> > > > > > > source, just to prove that we can indeed get the necessary
> > details
> > > > via
> > > > > > > Ambari's REST API.
> > > > > > > It generates a proper topology.xml descriptor based on a simple
> > > > > > descriptor
> > > > > > > (I chose YAML for this POC), which has a reference to what I've
> > > > called
> > > > > a
> > > > > > > policy descriptor (the  portion of the topology
> > > > descriptor).
> > > > > > >
> > > > > > > I am currently unable to update the KIP, but I can share the
> REST
> > > > APIs
> > > > > > I've
> > > > > > > employed if there is interest.
> > > > > > >
> > > > > > > As a result, I'm wondering if Knox should support provider
> > > > > configuration
> > > > > > > references in topology.xml, rather than having to duplicate it
> > > across
> > > > > > > descriptors.
> > > > > > > So, instead of ... in each
> > > > topology.xml,
> > > > > > have
> > > > > > > a single element that points to an external provider config
> > (e.g.,
> > > > > > > $GATEWAY_HOME/conf/policy/my-named-provider-
> > > > > > > config.xml).
> > > > > > > I've already externalized it for input to the POC, but I'm
> still
> > > > > copying
> > > > > > > the contents into the resulting topology descriptor; I think it
> > > would
> > > > > be
> > > > > > > better to copy only the reference.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > >  - Phil
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 18, 2017 at 1:55 PM, larry mccay <
> lmc...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Good to hear, Phil.
> > > > > > > >
> > > > > > > > Yes, I was looking to go back and add some of the API
> specifics
> > > and
> > > > > > > > investigation details for at least Ambari and ZK.
> > > > > > > > If others make sense to add such as Consul, etcd, etc that
> > would
> > > be
> > > > > > good
> > > > > > > as
> > > > > > > > well and it would help to tease out some of what may be
> needed
> > > for
> > > > > the
> > > > > > > > abstraction API and config.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 18, 2017 at 1:52 PM, Philip Zampino <
> > > > pzamp...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > This sounds 

[jira] [Commented] (KNOX-738) Remove references to deprecated httpclient class DefaultHttpClient

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148727#comment-16148727
 ] 

ASF subversion and git services commented on KNOX-738:
--

Commit f1bbea9b73d0e24454cf65a3c015b083f9247aa2 in knox's branch 
refs/heads/master from [~coheigea]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=f1bbea9 ]

KNOX-738 - Remove references to deprecated httpclient class DefaultHttpClient


> Remove references to deprecated httpclient class DefaultHttpClient
> --
>
> Key: KNOX-738
> URL: https://issues.apache.org/jira/browse/KNOX-738
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Sumit Gupta
>Assignee: Colm O hEigeartaigh
> Fix For: 0.14.0
>
>
> Need to get rid of deprecated DefaultHttpClient class references. Most, if 
> not all, occur in tests at this point since the Dispatch framework has 
> already moved on to the new classes and API from httpclient. 
> Besides cleaning up, the tests appear to have some erratic behavior on some 
> OS/jdk combinations with this deprecated class. These random test failures go 
> away when using the new classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-738) Remove references to deprecated httpclient class DefaultHttpClient

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated KNOX-738:
-
Fix Version/s: 0.14.0

> Remove references to deprecated httpclient class DefaultHttpClient
> --
>
> Key: KNOX-738
> URL: https://issues.apache.org/jira/browse/KNOX-738
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Sumit Gupta
>Assignee: Colm O hEigeartaigh
> Fix For: 0.14.0
>
>
> Need to get rid of deprecated DefaultHttpClient class references. Most, if 
> not all, occur in tests at this point since the Dispatch framework has 
> already moved on to the new classes and API from httpclient. 
> Besides cleaning up, the tests appear to have some erratic behavior on some 
> OS/jdk combinations with this deprecated class. These random test failures go 
> away when using the new classes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: KIP-8 Service Discovery and Topology Generation

[Krishna Pandey]

>
> As a result, I'm wondering if Knox should support provider configuration
> references in topology.xml, rather than having to duplicate it across
> descriptors.


+1 to Phil's remark above. Adding to that as Knox provides multi-cluster
support, can we have external provider config cluster-wise? Or we can
define multiple external provider config in single "global" provider config
file and refer them with some key?

Also, when services are deployed in HA, we specify HaProvider and multiple
Service URLs in the topology. Will it make sense to use Load balancer IP
address / External URL for those services in topology instead of multiple
service URLs and using HaProvider?

Thanks,
Krishna Pandey

On Wed, Aug 30, 2017 at 10:05 PM, larry mccay  wrote:

> Terrific, Phil!
>
>
> On Wed, Aug 30, 2017 at 11:03 AM, Philip Zampino 
> wrote:
>
> > After giving this KIP some thought, I would like to work on it. I've
> added
> > more detail to the wiki, and I'll create a JIRA for it.
> >
> > On Fri, Aug 25, 2017 at 10:03 AM, larry mccay  wrote:
> >
> > > Wonderful details, Phil!
> > >
> > >
> > > On Fri, Aug 25, 2017 at 9:40 AM, Philip Zampino 
> > > wrote:
> > >
> > > > Thanks! I've added the Ambari API details to the wiki.
> > > >
> > > > On Fri, Aug 25, 2017 at 8:27 AM, larry mccay 
> > wrote:
> > > >
> > > > > HI Phil -
> > > > >
> > > > > Thank you for digging into this topic!
> > > > >
> > > > > I've added you as a contributor to the wiki and you should be able
> to
> > > > edit
> > > > > the KIP now.
> > > > >
> > > > > thanks,
> > > > >
> > > > > --larry
> > > > >
> > > > > On Thu, Aug 24, 2017 at 3:45 PM, Philip Zampino <
> pzamp...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I've put together a quick python POC targeting Ambari as the
> > > discovery
> > > > > > source, just to prove that we can indeed get the necessary
> details
> > > via
> > > > > > Ambari's REST API.
> > > > > > It generates a proper topology.xml descriptor based on a simple
> > > > > descriptor
> > > > > > (I chose YAML for this POC), which has a reference to what I've
> > > called
> > > > a
> > > > > > policy descriptor (the  portion of the topology
> > > descriptor).
> > > > > >
> > > > > > I am currently unable to update the KIP, but I can share the REST
> > > APIs
> > > > > I've
> > > > > > employed if there is interest.
> > > > > >
> > > > > > As a result, I'm wondering if Knox should support provider
> > > > configuration
> > > > > > references in topology.xml, rather than having to duplicate it
> > across
> > > > > > descriptors.
> > > > > > So, instead of ... in each
> > > topology.xml,
> > > > > have
> > > > > > a single element that points to an external provider config
> (e.g.,
> > > > > > $GATEWAY_HOME/conf/policy/my-named-provider-
> > > > > > config.xml).
> > > > > > I've already externalized it for input to the POC, but I'm still
> > > > copying
> > > > > > the contents into the resulting topology descriptor; I think it
> > would
> > > > be
> > > > > > better to copy only the reference.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > >  - Phil
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 18, 2017 at 1:55 PM, larry mccay 
> > > > wrote:
> > > > > >
> > > > > > > Good to hear, Phil.
> > > > > > >
> > > > > > > Yes, I was looking to go back and add some of the API specifics
> > and
> > > > > > > investigation details for at least Ambari and ZK.
> > > > > > > If others make sense to add such as Consul, etcd, etc that
> would
> > be
> > > > > good
> > > > > > as
> > > > > > > well and it would help to tease out some of what may be needed
> > for
> > > > the
> > > > > > > abstraction API and config.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 18, 2017 at 1:52 PM, Philip Zampino <
> > > pzamp...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > This sounds like a good improvement from a usability
> > perspective.
> > > > > > > >
> > > > > > > > I agree that Knox must continue its support for direct
> topology
> > > > (XML)
> > > > > > > > definitions, but for those deployments where there is a
> service
> > > > > > registry
> > > > > > > > (e.g., Ambari, Zookeeper, Consul, etc...) with knowledge of
> the
> > > > > > topology,
> > > > > > > > the simplified config coupled with the service discovery
> could
> > > > reduce
> > > > > > > > topology (especially ServiceConnectivity) errors.
> > > > > > > >
> > > > > > > > I also agree that consolidating provider configurations into
> > > named
> > > > > > sets,
> > > > > > > > which can be referenced from topology configurations, will
> be a
> > > > good
> > > > > > > > change, especially if there are commonly grouped providers
> > > employed
> > > > > by
> > > > > > > > multiple topologies.
> > > > > > > >
> > > > > > > > Concerning the TODO sections, is your intention is that they
> > > > contain
> > > > > > the
> > > > > > > >