[Gluster-devel] pluggability of some aspects in afr/nsr/ec

[Pranith Kumar Karampuri]

On 10/29/2015 12:18 PM, Venky Shankar wrote:
> On Thu, Oct 29, 2015 at 11:36 AM, Pranith Kumar Karampuri
> <pkarampu at redhat.com> wrote:
>> hi,
>>           I want to understand how are you guys planning to integrate NSR
>> volumes to the existing CLIs. Here are some thoughts I had, wanted to know
>> your thoughts:
>> At the heart of both the replication/ec schemes we have
>> 1) synchronization mechanisms
>>         a) afr,ec does it using locks
>>         b) nsr does it using leader election
>> 2) Metadata to figure out the healing/reconciliation aspects
>>         a) afr,ec does it using xattrs
>>         b) nsr does it using journals
>>
>> I want to understand if there is a possibility of exposing these as
>> different modules that we can mix and match, using options. If the users
> Do you mean abstracting it out during volume creation? At a high level
> this could be in the form of client or server
> side replication. Not that AFR cannot be used on the server side
> (you'd know better than me), but, if at all this level
> of abstraction is used, we'd need to default to what fits best in what
> use case (as you already mentioned below)
> but still retaining the flexibility to override it.
precisely. I think switching is not that difficult once we make sure 
healing is complete. Switching is a rare operation IMO so we can 
probably ask the users to do stop/choose-new-value/start the volume 
after choosing the options. This way is simpler than to migrate between 
the volumes where you have to probably copy the data.

Pranith
>
>> choose 1b, 2b it becomes nsr and 1a, 2a becomes afr/ec. In future if we come
>> up with better metadata journals/stores it should be easy to plug them is
>> what I'm thinking. The idea I have is based on the workload, users should be
>> able to decide which pair of synchronization/metadata works best for them
>> (Or we can also recommend based on our tests). Wanted to seek your inputs.
>>
>> Pranith
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel