You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Kevin Minder (JIRA)" <ji...@apache.org> on 2013/10/25 14:59:31 UTC

[jira] [Commented] (KNOX-145) Integrate with ZooKeeper for config and topology syncronization

    [ 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)