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
