[Gluster-devel] break glusterd into small parts (Re: good job on fixing heavy hitters in spurious regressions)

[Pranith Kumar Karampuri]

On 05/09/2015 04:23 PM, Krishnan Parthasarathi wrote:
>> Oh nice, I might have missed the mails. Do you mind sharing the plan for
>> 4.0? Any reason why you guys do not want to continue glusterd as
>> translator model?
> I don't understand why we are using the translator model in the first place.
> I guess it was to reuse rpc code. You should be able to shed more light here.
Even I am not sure :-). It was a translator by the time I got in.
> A quick google search with "glusterd 2.0 gluster-users", gave me this
> http://www.gluster.org/pipermail/gluster-users/2014-September/018639.html.
> Interestingly you asked us to consider AFR/NSR for distributed configuration
> management, which lead to http://www.gluster.org/pipermail/gluster-devel/2014-November/042944.html
> This proposal didn't go in the expected direction.
>
> I don't want to get into "why not use translators" now. We are currently heading in the
> direction visible in the above threads. If glusterd can't be a translator anymore, so be it.
Kaushal's response gave the answers I was looking for. We should 
probably discuss it more once you guys come up with the interface CLI 
handling code needs to follow. I was thinking it would be great if you 
come up with a model where the handler code will be separate from the 
code of glusterd, which is what you guys seem to be targeting. 
Translator model is one way of achieving it, I personally love it on the 
FS side, that is why I was curious why it was not used. But any other 
way where the above requirements are met is welcome.
Really excited to see what will come up :-).

Pranith