diff options
author | Kaushal M <kshlmster@gmail.com> | 2016-01-20 13:09:23 +0530 |
---|---|---|
committer | Raghavendra Talur <rtalur@redhat.com> | 2016-01-27 22:23:22 -0800 |
commit | 601bfa2719d8c9be40982b8a6526c21cd0ea4966 (patch) | |
tree | d7d37c778873907ca98cf7c9961bc9686c3d182f /under_review/volgen-rewrite.md | |
parent | 063b5556d7271bfe06ec80b6a1957fbd5cacec51 (diff) |
Rename in_progress to under_review
`in_progress` is vague term, which could either mean the feature
review is in progress, or that the feature implementation is in
progress.
Renaming to `under_review` gives a much better indication that the
feature is under review and implementation hasn't begun yet.
Refer https://review.gluster.org/13187 for the discussion which
lead to this
Change-Id: I3f48e15deb4cf5486d7b8cac4a7915f9925f38f5
Signed-off-by: Kaushal M <kshlmster@gmail.com>
Reviewed-on: http://review.gluster.org/13264
Reviewed-by: Raghavendra Talur <rtalur@redhat.com>
Tested-by: Raghavendra Talur <rtalur@redhat.com>
Diffstat (limited to 'under_review/volgen-rewrite.md')
-rw-r--r-- | under_review/volgen-rewrite.md | 128 |
1 files changed, 128 insertions, 0 deletions
diff --git a/under_review/volgen-rewrite.md b/under_review/volgen-rewrite.md new file mode 100644 index 0000000..4b954b3 --- /dev/null +++ b/under_review/volgen-rewrite.md @@ -0,0 +1,128 @@ +Feature +------- + +Volgen rewrite + +Summary +------- + +This module has become an important choke point for development of new +features, as each new feature needs to make changes here. Many previous +feature additions have been rushed in, by copying/pasting code or adding +special-case checks, instead of refactoring. The result is a big +hairball. Every new change that involves client translators has to deal +with various permutations of replication/EC, striping/sharding, +rebalance, self-heal, quota, snapshots, tiering, NFS, and so on. Each +new change at this point is almost certain to introduce subtle errors +that will only be caught when certain combinations of features and +operations are attempted. There aren't even enough tests to cover even +the basic combinations, and we'd need hundreds more to test the obscure +ones. + +Owners +------ + +Jeff Darcy <jdarcy@redhat.com> + +Current status +-------------- + +Just a proposal so far. + +Related Feature Requests and Bugs +--------------------------------- + +TBD + +Detailed Description +-------------------- + +Many of the problems stem from the fact that our internal volfiles need +to be consistent with, but slightly different from, one another. Instead +of generating them all separately, we should separate the generation +into two phases: + +* Generate a "core" or "vanilla" graph containing all of the translators, option settings, etc. common to all of the special-purpose volfiles. + +* For each special-purpose volfile, copy the core/vanilla graph (*not the code* that generated it) and modify the copy to get what's desired. + +Some of the other problems in this module stem from lower-level issues +such as bad data- or control-structure choices (e.g. operating on a +linear list of bricks instead of a proper graph), or complex +object-lifecycle management (e.g. see +<https://bugzilla.redhat.com/show_bug.cgi?id=1211749>). Some of these +problems might be alleviated by using a higher-level language with +complex data structures and garbage collection. An infrastructure +already exists to do graph manipulation in Python, developed for HekaFS +and subsequently used in several other places (it's already in our +source tree). + +Benefit to GlusterFS +-------------------- + +More correct, and more \*verifiably\* correct, volfile generation even +as the next dozen features are added. Also, accelerated development time +for those next dozen features. + +Scope +----- + +### Nature of proposed change + +Pretty much limited to what currently exists in glusterd-volgen.c + +### Implications on manageability + +None. + +### Implications on presentation layer + +None. + +### Implications on persistence layer + +None. + +### Implications on 'GlusterFS' backend + +None. + +### Modification to GlusterFS metadata + +None. + +### Implications on 'glusterd' + +None, unless we decide to store volfiles in a different format (e.g. +JSON) so we can use someone else's parser instead of rolling our own. + +How To Test +----------- + +Practically every current test generates multiple volfiles, which will +quickly smoke out any differences. Ideally, we'd add a bunch more tests +(many of which might fail against current code) to verify correctness of +results for particularly troublesome combinations of features. + +User Experience +--------------- + +None. + +Dependencies +------------ + +None. + +Documentation +------------- + +None. + +Status +------ + +Still just a proposal. + +Comments and Discussion +----------------------- |