[Gluster-devel] Volume management proposal (4.0)

[Jeff Darcy]

> > (D) Secondary volumes may not be started and stopped by the user.
> > Instead, a secondary volume is automatically started or stopped along
> > with its primary.
> 
> Wouldn't it help in some cases to have secondary volumes running while
> primary is not running? Some form of maintenance activity.

Yes, that's true.

> > (E) The user must specify an explicit option to see the status of
> > secondary volumes.  Without this option, secondary volumes are hidden
> > and status for their constituent bricks will be shown as though they
> > were (directly) part of the corresponding primary volume.
> > 
> > As it turns out, most of the "extra" volfiles in step 8 above also
> > have their own steps 6d and 7, so implementing step C will probably make
> > those paths simpler as well.
> > 
> > The one big remaining question is how this will work in terms of
> > detecting and responding to volume configuration changes.  Currently we
> > treat each volfile as a completely independent entity, and just compare
> > whole graphs.  Instead, what we need to do is track dependencies between
> > graphs (a graph of graphs?) so that a change to a secondary volume will
> > "ripple up" to its primary where a new graph can be generated and
> > compared to its predecessor.
> 
> IIUC, (E) describes that primary volume file would be generated with all
> secondary volume references resolved. Wouldn't that preclude the possibility
> of the respective processes discovering the dependencies?

That's not entirely clear.  The *volfiles* might not contain the necessary
information, depending on exactly when we resolve references to other
volumes - e.g. at creation, volfile-fetch, or even periodically.  However,
the *info* files from which the volfiles are generated would necessarily
include at least the parent-to-child links.  We could scan all info files
during any configuration change to find such dependencies.  Even better,
we could also store the child-to-parent links as well, so when we change
X we *immediately* know whether that might affect a parent volume.