summaryrefslogtreecommitdiffstats
path: root/doc
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 07:31:30 -0700
commitc5a19652c80162e670d29a7bd8c910d0acdfacb9 (patch)
tree0c6295a5b62c39379ae8205728ced82541a2a53b /doc
parent2ddb41874d94a925828bf3cd042b4f3f77897343 (diff)
glusterd: initialize the daemon services on demand
Backport of http://review.gluster.org/#/c/11488/ 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: 1247012 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> Reviewed-on: http://review.gluster.org/11766
Diffstat (limited to 'doc')
-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