From: "Pranith Kumar Karampuri" <address@hidden>
To: "Anand Avati" <address@hidden>
Cc: "Ravishankar N" <address@hidden>, "Gluster Devel" <address@hidden>
Sent: Wednesday, February 12, 2014 11:44:08 AM
Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
----- Original Message -----
From: "Pranith Kumar Karampuri" <address@hidden>
To: "Anand Avati" <address@hidden>
Cc: "Ravishankar N" <address@hidden>, "Gluster Devel"
<address@hidden>
Sent: Wednesday, February 12, 2014 11:16:57 AM
Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
----- Original Message -----
From: "Anand Avati" <address@hidden>
To: "Ravishankar N" <address@hidden>
Cc: "Gluster Devel" <address@hidden>
Sent: Wednesday, February 12, 2014 10:30:29 AM
Subject: Re: [Gluster-devel] Persistent AFR changelog attributes
Ravi,
We had earlier discussed a solution for this (sometime last year) by
making
volgen remember xlator names and not reassign them. Copying KP with who I
had discussed this to quite a level of detail. Have you guys spoken about
this? IIRC the solution KP and I discussed was more generic and could
also
support retaining user made changes/customizations to the volfiles.
How will new machines that are joining the cluster will know about this
modified graph? One way to achieve it is to send the skeleton structure of
the graph to other machines. I wonder how this will address snapshot
volumes' graph. May be even in the case of snapshot volumes, the skeleton
has to be copied over to snapshot volume. So instead of storing just the
client xlator names, the generic solution will have to store the entire
skeleton and should keep it in sync at the time of probe, snapshot. Is that
the rough algo you guys discussed? Did I miss anything?
If this indeed is the approach, I don't see an easy way out for generating
brick volfiles according to versions. Brick processes don't have graph
switching capability yet. Because of this, new versions may need to generate
new xlators (Ex: barrier xlator that is going to come in for 3.6) in new
versions but not for old versions. In essence the skeleton that is stored
for one version could be incompatible for other versions. Then we will have
to start having some sort of conversion mechanisms of the skeletons from one
version to other. It seems a bit complicated :-(. Any suggestions?