[Gluster-devel] State of op-version

[Kaushal M]

Hi Everyone,

I'd like to give an overview on the current state of op-version in gluster and 
what is left to be done.

Presently, op-version has been implemented as per the design described on the 
feature page [1]. The volume op-versions and reduction of op-version are the 
only parts remaining according to the design.
I have a patch for volume op-version under review at [2]. The reduction of 
op-version will be a trivial change once volume op-version is completed.

The current design and implementation works well for handling upgrades, ie. 
prevent new features from being enabled and breaking the cluster before 
everyone is upgraded. The design was done to solve this particular problem.

But, with this design we have a problem with freshly installed clusters. Newly 
available features won't be available on these clusters until explicitly 
enabled, as the design requires all new features to be disabled by default.

This is the case with the open-behind translator. At present it is enabled by 
default, which goes against the requirement of new features being disabled. So 
I sent a patch [3] to disable it for review. During the review process, Avati, 
KP and me had a discussion and came to conclusion that the design required 
changes. The following new requirements were found,
 * new installations should start at maximum possible op-version
 * new features should be enabled or disabled automatically based on the 
cluster-op-version

To address the above requirements, I've implemented a significant change to the 
old design. The patch is under review at [4]. With this patch, I believe I've 
satisfied the original and new requirements, except the requirement of 
automatically enabling features based on op-version. Addressing this 
requirement will require a significant change in the volgen code to have a 
proper/correct solution and which will take a lot of time IMO. The above patch 
[4] also hasn't been tested as much yet and may yet contain several corner 
cases which could cause unintended failures. The problem going ahead with the 
new solution is that, with release of 3.4 (beta) expected to happen soon, this 
would cause possibly unstable/untested code to be in.

We need to take a decision on this. In my view we have the following choices,

1. Accept the open-behind disable patch [3] and stay with the relatively 
more(well) tested implementation of the original design.
2. Accept the implementation of the newer design [4] with a small hack  in 
volgen just to satisfy the requirement for open-behind
3. (Possibly?) Push back the release (for how long?) and complete the newer 
implementation [4] to have correct volgen implementation for all 
options/features.


IMO, option 1 is the safest at the present even though we give up the newer 
requirements, as it requires the smallest amount of change, which leads to 
lesser chance of encountering problems.

What are your opinions?

- Kaushal

---------------------------------------------------------------------------------
[1] - 
http://www.gluster.org/community/documentation/index.php/Features/Opversion
[2] - http://review.gluster.org/4584
[3] - http://review.gluster.org/4481
[4] - http://review.gluster.org/4598