> > (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. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
