You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by Philip Zampino <pz...@gmail.com> on 2017/08/30 22:31:21 UTC
[DISCUSS] KNOX-1006 sub tasks
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
Re: [DISCUSS] KNOX-1006 sub tasks
Posted by Sandeep More <mo...@gmail.com>.
Great,
Ya separate JIRAs and may be referenced in KIP so we can keep track of it.
Thanks for the detailed writeup Philip !
Best,
Sandeep
On Wed, Aug 30, 2017 at 7:01 PM, larry mccay <lm...@apache.org> wrote:
> Looks great.
> These can be broken out as separate child JIRAs.
>
> Thanks!
>
> --larry
>
> On Wed, Aug 30, 2017 at 6:31 PM, Philip Zampino <pz...@gmail.com>
> wrote:
>
> > 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
> >
>
Re: [DISCUSS] KNOX-1006 sub tasks
Posted by larry mccay <lm...@apache.org>.
Looks great.
These can be broken out as separate child JIRAs.
Thanks!
--larry
On Wed, Aug 30, 2017 at 6:31 PM, Philip Zampino <pz...@gmail.com> wrote:
> 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
>