I am also in process of migrating (just started) existing rebalance
daemon code into the new framework. bricks will be the next in the
queue. As pointed out by KP, please allow the new daemons to follow this
framework and believe me managing these daemons will be much more easier
than we had before
All,
We have merged the "Daemon management refactoring" changes[1]
successfully. Thanks you for all those who reviewed it. As part
of this patch we have moved gluster-NFS, gluster self-heal daemon,
quota daemon and snapshot daemon (for serving User servicable snapshots)
into the new framework. Thi
[Apologies for sending an incomplete message]
While implementing daemon management code as proposed here, I found it wasn't
possible to embed structures that are abstract data types (ADT). In short,
ADT's 'real' size is unknown to the containing type and compilation fails. This
brings us to which
While modelling daemons as proposed here, I noticed that I didn't
foresee thathow abstract data types and embedded structures
(think struct list_head)
- Original Message -
> Here is the first patch, http://review.gluster.org/9278, which marks the
> beginning
> of the implementation phase
Here is the first patch, http://review.gluster.org/9278, which marks the
beginning
of the implementation phase of this refactoring effort. Reviews/comments for
the (design) proposal
helped us to correct a few things and kick start coding. Look forward to see
the same enthusiasm
with the code rev
On 2014-12-12 10:26, Krishnan Parthasarathi wrote:
> Anders,
>
### Abstract data types
struct conn_mgmt {
struct rpc_clnt *rpc;
int (*connect) (struct conn_mgmt *self);
int (*disconnect) (struct conn_mgmt self);
Anders,
> >> ### 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_ev
On 2014-12-09 16:23, Anders Blomdell wrote:
> On 2014-12-09 13:18, Krishnan Parthasarathi wrote:
>> 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
>>
On 12/09/2014 06:24 PM, Jeff Darcy wrote:
>> 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
>> a
On 2014-12-09 13:18, Krishnan Parthasarathi wrote:
> 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 propos
I had the exact same comment on this when KP showed this to me before.
I'm pasting the response I'd given then.
It would also be good if have the service itself be a standard type.
This is along the lines of the xlator class we have. This way we could
have standard implementations of the various
> 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 approac
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.
13 matches
Mail list logo
