Description of problem:
RHGS currently ships all xlators in the code base, including those that are not supported by Red Hat. This can sometimes cause issues when customers try out features which are not supported downstream.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Lets get this done in upstream, and then get this to downstream, eventually? Anyways, the work towards this is started upstream #bz1635688
Here is what I think of it.
> I suppose the verification of this bug would include
> * to check if the corresponding volume options related to the xlators mentioned in comment 6 and 9 to either not be configurable at all, OR to display a warning if an attempt is made to enable the same (?)
> * To enable these xlators (need to know how) in a previous release (say 3.4.x) and then try to upgrade to 3.5 and validate if the update fails/aborts, stating a valid reason
Not critical. As these are 'deprecated' xlators already in 3.4.x releases (we are not deprecating anything new in 3.5.0, ie in 3.x series). You can skip it. Or, try it, but even if it fails, lets document the behavior.
> Additonal queries that would help in successfully validating this RFE:
> * Any other way to confirm the change in spec file (?) than the scenarios mentioned above?
Try `gluster system getspec VOLUME_NAME` (if the translator is on client side). Or else spec file.
But notice, we should be actually checking for '*.so' file (ie, translator image) in corresponding release path. Say, diff of content in
This is where this bug would be validated.
> * Any other volume options/xlators that have been disabled/discontinued , which are not made a mention of in comment 6 and 9 put together?
Not that I am aware of.
> * Any visible change in functionality/output-of-usual-commands to be expected with all the patches that have been linked to BZ1635688?
Nope. Nothing I am aware of.