[
https://issues.apache.org/jira/browse/KNOX-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805280#comment-13805280
]
Kevin Minder commented on KNOX-145:
-----------------------------------
I'm thinking that this would be the structure in Zookeeper. I've included the
/knox/{cluster} level because there may be more than one cluster of Knox
instances managed by a single Zookeeper "service". This is debatable. Given
the structure a Zookeeper client embedded in each Knox process would watch the
appropriate /knox/{cluster} namespace for changes. Anything under
/knox/{cluster}/conf would require a restart of that instance and anything
under /knox/{cluster}/deployments could be deployed dynamically. There is
probably some additional book keeping that is required so that a knox instance
that was not running when a change was made in Zookeeper can figure out that it
has stale data.
/knox
/{cluster}
/conf
/gateway-site.xml
/log4j.properties
/security
/master
/registry
/keystores
/__gateway-credentials.jceks
/gateway.jks
/{topology}-credentials.jceks
/deployments
/{topology}.xml
> Integrate with ZooKeeper for config and topology syncronization
> ---------------------------------------------------------------
>
> Key: KNOX-145
> URL: https://issues.apache.org/jira/browse/KNOX-145
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Affects Versions: 0.3.0
> Reporter: Kevin Minder
> Fix For: 0.4.0
>
>
> We should consider using ZooKeeper for config and topo sync. In this model
> Ambari would publish changes to one or more ZK nodes. These changes would be
> detected by each Knox instance. The changes would be written to local disk
> and then "activated". Some changes might require server restart which would
> not be ideal. Ideally all changes could be applied without starting the
> server. This must be the case for topo changes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
