All,
I would like to propose refactoring of the code managing
various daemons in glusterd. Unlike other high(er) level proposals
about feature design, this one is at the implementation
level. Please go through the details of the proposal below
and share your thoughts/suggestions on the approach.
### Introduction
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.
- Connection Management
- unix domain sockets based channel for internal communication
- Methods - connect, disconnect, notify
- Process Management
- pidfile to detect if the daemon is running
- Environment; run-dir, svc-dir, log-dir etc.
- Methods - start, stop, status, kill
- Daemon-specific Management
Currently, the daemon management code is fragmented and doesn't elicit the
structure described above. This results in further fragmentation since new
developers may not identify common patterns, worse even, they won't be able to
do anything about it.
This proposal aims to do the following,
- Provide an abstract data type that encapsulates what is common among daemons
that are managed by glusterd.
- 'Port' existing code to make use of the abstract type. This would help in
making this change self-documented to an extent.
- Prescribe a way to maintain per-feature daemon code separate to glusterd's
common code.
### Abstract data types
struct conn_mgmt {
struct rpc_clnt *rpc;
int (*connect) (struct conn_mgmt *self);
int (*disconnect) (struct conn_mgmt self);
int (*notify) (struct conn_mgmt *self, rpc_clnt_event_t *rpc_event);
}
struct proc_mgmt {
char svcdir[PATH_MAX];
char rundir[PATH_MAX];
char logdir[PATH_MAX];
char pidfile[PATH_MAX];
char logfile[PATH_MAX];
char volid[UUID_CANONICAL_FORM_LEN];
int (*start) (struct proc_mgmt *self, int flags);
int (*stop) (struct proc_mgmt *self, int flags);
int (*is_running) (struct proc_mgmt *self);
int (*kill) (struct proc_mgmt *self, int flags);
}
Feature authors can define data type representing their service by implementing
the above 'abstract' class. For e.g,
struct my_service {
char name[PATH_MAX];
/* my_service specific data members and methods */
/* The methods in the following structures should be implemented by
respective feature authors */
struct conn_mgmt conn;
struct proc_mgmt proc;
}
### Code structure guidelines
Each feature that introduces a daemon would implement the abstract data type.
The implementations should be in separate files named appropriately. The intent
is to avoid feature specific code to leak into common glusterd codebase.
glusterd-utils.c is testament to such practices in the past.
For e.g,
[kp@trantor glusterd]$ tree
.
└── src
├── glusterd-conn-mgmt.c
├── glusterd-conn-mgmt.h
├── glusterd-proc-mgmt.c
├── glusterd-proc-mgmt.h
├── my-feature-service.c
└── my-feature-service.h
[kp@trantor glusterd]$ cat src/my-feature-service.h
#include "glusterd-conn-mgmt.h"
#include "glusterd-proc-mgmt.h"
...
[rest of the code elided]
### Bibliography
- Object-oriented design patterns in the kernel, part 1 - http://lwn.net/Articles/444910/
- Object-oriented design patterns in the kernel, part 2 - http://lwn.net/Articles/446317/
thanks,
kp
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
