STORM-166: reformatting some sections.
Project: http://git-wip-us.apache.org/repos/asf/storm/repo Commit: http://git-wip-us.apache.org/repos/asf/storm/commit/e05d6663 Tree: http://git-wip-us.apache.org/repos/asf/storm/tree/e05d6663 Diff: http://git-wip-us.apache.org/repos/asf/storm/diff/e05d6663 Branch: refs/heads/nimbus-ha-branch Commit: e05d6663a3dbc056e9f21194f83fe0e27509f83e Parents: 07b69b7 Author: Parth Brahmbhatt <[email protected]> Authored: Fri Dec 19 13:01:27 2014 -0800 Committer: Parth Brahmbhatt <[email protected]> Committed: Fri Dec 19 13:01:27 2014 -0800 ---------------------------------------------------------------------- docs/documentation/nimbus-ha-design.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/storm/blob/e05d6663/docs/documentation/nimbus-ha-design.md ---------------------------------------------------------------------- diff --git a/docs/documentation/nimbus-ha-design.md b/docs/documentation/nimbus-ha-design.md index 51b15f8..cb6332f 100644 --- a/docs/documentation/nimbus-ha-design.md +++ b/docs/documentation/nimbus-ha-design.md @@ -13,9 +13,8 @@ of the backups will take over. the list of potential leaders automatically. * No topology resubmissions required in case of nimbus fail overs. * No active topology should ever be lost. -##Components: -Following are different components to achieve the above goals. -###Leader Election: + +##Leader Election: The nimbus server will use the following interface: ```java @@ -81,7 +80,7 @@ This sequence diagram describes how leader election and failover would work with  -###Nimbus state store: +##Nimbus state store: Currently the nimbus stores 2 kind of data * Meta information like supervisor info, assignment info which is stored in zookeeper @@ -93,9 +92,9 @@ and it is hard to test for correctness.However many storm users do not want to t storage system like HDFS and still need high availability.Eventually, we want to move to the bittorrent protocol for code distribution given the size of the jars and to achieve better scaling when the total number of supervisors is very high. The current file system based model for code distribution works fine with systems that have file system like structure -but it fails to support a non file system based approach like bit torrent. To support bit torrent we can go with the -following interface instead of the storage interface described above. The interface described below can still be used with -HDFS,S3 and local file system, so this is a more extensible interface. +but it fails to support a non file system based approach like bit torrent. To support bit torrent and all the file +system based replicated storage systems we propose the following interface: + ```java /** * Interface responsible to distribute code in the cluster.
