summaryrefslogtreecommitdiffstats
path: root/doc/developer-guide/daemon-management-framework.md
diff options
context:
space:
mode:
authorAtin Mukherjee <amukherj@redhat.com>2015-07-01 14:47:48 +0530
committerKaushal M <kaushal@redhat.com>2015-07-27 00:14:01 -0700
commitd49b4b1086119873664b77ea7d7f2a5dd8f671ee (patch)
treed29051a5daf4fff7e7debb6cf5ff2a737c0a993d /doc/developer-guide/daemon-management-framework.md
parentfd296d90168002a475a9899a72a0dd1811f038ee (diff)
glusterd: initialize the daemon services on demand
As of now all the daemon services are initialized at glusterD init path. Since socket file path of per node daemon demands the uuid of the node, MY_UUID macro is invoked as part of the initialization. The above flow breaks the usecases where a gluster image is built following a template could be Dockerfile, Vagrantfile or any kind of virtualization environment. This means bringing instances of this image would have same UUIDs for the node resulting in peer probe failure. Solution is to lazily initialize the services on demand. Change-Id: If7caa533026c83e98c7c7678bded67085d0bbc1e BUG: 1238135 Signed-off-by: Atin Mukherjee <amukherj@redhat.com> Reviewed-on: http://review.gluster.org/11488 Tested-by: Gluster Build System <jenkins@build.gluster.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org> Reviewed-by: Gaurav Kumar Garg <ggarg@redhat.com> Reviewed-by: Kaushal M <kaushal@redhat.com>
Diffstat (limited to 'doc/developer-guide/daemon-management-framework.md')
-rw-r--r--doc/developer-guide/daemon-management-framework.md9
1 files changed, 6 insertions, 3 deletions
diff --git a/doc/developer-guide/daemon-management-framework.md b/doc/developer-guide/daemon-management-framework.md
index 592192e665d..cf29caa95ce 100644
--- a/doc/developer-guide/daemon-management-framework.md
+++ b/doc/developer-guide/daemon-management-framework.md
@@ -25,9 +25,12 @@ Data members & functions of different management objects
- connection object
- process object
- online status
- - Methods - manager, start, stop which can be abstracted as a common methods
- or specific to service requirements
- - init API can be invoked using the service management object
+ - Methods
+ -- manager, start, stop which can be abstracted as a common
+ methods or specific to service requirements
+ -- init API is invoked on demand of the service and currently integrated
+ into manager.
+ -- build method is to initialize the method pointers
The above structures defines the skeleton of the daemon management framework.
Introduction of new daemons in GlusterFS needs to inherit these properties. Any