summaryrefslogtreecommitdiffstats
path: root/Feature Planning/GlusterFS 4.0/volgen-rewrite.md
diff options
context:
space:
mode:
Diffstat (limited to 'Feature Planning/GlusterFS 4.0/volgen-rewrite.md')
-rw-r--r--Feature Planning/GlusterFS 4.0/volgen-rewrite.md128
1 files changed, 128 insertions, 0 deletions
diff --git a/Feature Planning/GlusterFS 4.0/volgen-rewrite.md b/Feature Planning/GlusterFS 4.0/volgen-rewrite.md
new file mode 100644
index 0000000..4b954b3
--- /dev/null
+++ b/Feature Planning/GlusterFS 4.0/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
+-----------------------