1 files changed, 38 insertions, 0 deletions
diff --git a/doc/developer-guide/daemon-management-framework.md b/doc/developer-guide/daemon-management-framework.md
new file mode 100644
index 00000000000..592192e665d
--- /dev/null
+++ b/doc/developer-guide/daemon-management-framework.md
@@ -0,0 +1,38 @@
+
+How to introduce new daemons using daemon management framework
+==============================================================
+Glusterd manages GlusterFS daemons providing services like NFS, Proactive
+self-heal, Quota, User servicable snapshots etc. Following are some of the
+aspects that come under daemon management.
+
+Data members & functions of different management objects
+
+- **Connection Management**
+    - unix domain sockets based channel for internal communication
+    - rpc connection for the communication
+    - frame timeout value for UDS
+    - Methods - notify
+    - init, connect, termination, disconnect APIs can be invoked using the
+      connection management object
+
+- **Process Management**
+    - Name of the process
+    - pidfile to detect if the daemon is running
+    - loggging directory, log file, volfile, volfileserver & volfileid
+    - init, stop APIs can be invoked using the process management object
+
+- **Service Management**
+    - 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
+
+ The above structures defines the skeleton of the daemon management framework.
+ Introduction of new daemons in GlusterFS needs to inherit these properties. Any
+ requirement specific to a daemon needs to be implemented in its own service
+ (for eg : snapd defines its own type glusterd_snapdsvc_t using glusterd_svc_t
+ and snapd specific data). New daemons will need to have its own service specific
+ code written in glusterd-<feature>-svc.h{c} and need to reuse the existing
+ framework.