[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gluster-devel] State of op-version
From: |
Kaushal M |
Subject: |
[Gluster-devel] State of op-version |
Date: |
Wed, 20 Mar 2013 08:39:41 -0400 (EDT) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gluster-devel] State of op-version,
Kaushal M <=