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

Kevin Minder edited comment on KNOX-145 at 10/25/13 1:01 PM:
-------------------------------------------------------------

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
/knox/{cluster}/conf/log4j.properties
/knox/{cluster}/conf/security/master
/knox/{cluster}/conf/security/keystores/__gateway-credentials.jceks
/knox/{cluster}/conf/security/keystores/gateway.jks
/knox/{cluster}/conf/security/keystores/{topology}-credentials.jceks
/knox/{cluster}/conf/security/keystores/deployments
/knox/{cluster}/deployments/{topology}.xml


was (Author: kminder):
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)

Reply via email to