diff options
| author | Atin Mukherjee <amukherj@redhat.com> | 2015-07-01 14:47:48 +0530 |
|---|---|---|
| committer | Kaushal M <kaushal@redhat.com> | 2015-07-27 07:31:30 -0700 |
| commit | c5a19652c80162e670d29a7bd8c910d0acdfacb9 (patch) | |
| tree | 0c6295a5b62c39379ae8205728ced82541a2a53b /doc | |
| parent | 2ddb41874d94a925828bf3cd042b4f3f77897343 (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.md | 9 |
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 |