[Gluster-devel] Volume management proposal (4.0)

[Jeff Darcy]

> Persisting the volume relationships in the volume info file
> (i.e, /var/lib/glusterd/vols/VOLNAME/info) is a good idea. With this we could
> contain volume (relationship) management within the management plane.
> Do you have ideas on how to persist volume relationships?

It seems simplest to store child-parent relationships (one to one)
instead of parent-child relationships (one to many).  Based on that, I
looked at some info files and saw that we're already using
"parent_volname" for snapshot stuff.  Maybe we need to change
terminology.  Let's say that we use "part-of" in the info file.

* Create a new string-valued glusterd_volinfo_t.part_of field.

* This gets filled in from glusterd_store_update_volinfo along with
  everything else from the info file.

* When a composite volume is created, its component volumes' info files
  are rewritten.

* When a component volume is modified, use the part_of field to find its
  parent.  We then generate the fully-resolved client volfiles before
  and after the change and compare for differences.

* If we find differences in the parent, process the change as though it
  had been made on the parent (triggering graph switches etc.) and then
  use the parent's part_of field to repeat the process one level up.

I don't think we need to do anything for server-side-only changes, since
those will already be handled (e.g. starting new bricks) by the existing
infrastructure.  However, things like NFS and quotad might need to go
through the same process outlined above for clients.