I have in mind the following sub-tasks associated with KNOX-1006
<https://issues.apache.org/jira/browse/KNOX-1006> (Service Discovey and
Topology Generation),
for which I’m going to create JIRA issues.
I believe many of them can be worked on fairly independently, but there are
some obvious dependencies.
*Support externalization of provider config from topology descriptors (no
dependency)*
- Define external config content format (the same as today, but a
separate document with a <gateway/> 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 <gateway/> content
- Includes determining how externalized provider config changes are
propagated to deployed topologies.
*Knox config remote discovery (no dependency)*
- Define 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
*Implement the heart of the service discovery and topology generation
framework (no initial dependency)*
- 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?)
*ZooKeeper Monitor for Knox config changes (affecting existing deployed
topologies)*
* - *Related to* Knox config remote discovery*
- 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
*Monitor for Ambari cluster topology changes (i.e., service URL changes)*
- Includes Knox dynamic response to such changes
*ZooKeeper service discovery (depends on discovery framework)*
*Monitor for ZooKeeper cluster topology changes (i.e., service URL changes)*
- Includes Knox dynamic response to such changes
