Hide Forgot
Description of problem: From resource agent description: partial_activation: If set, the volume group will be activated even only partial of the physical volumes available. It helps to set to true, when you are using mirroring logical volumes. Default value for partial_activation is False. Now we support other raid types as well it would make in my opinion more sense to True because: * with volumes that are not raid volumes this choice makes no sense * with raid volume being: * healthy, resource agent would activate vg with either value * degraded, but working raid: this is the only case where we would always want to have partial_activation=true (or the raid would make no sense) * faulty raid (two many failed disks to work) vg would not be activated with either value because it cant be activated Version-Release number of selected component (if applicable): resource-agents-3.9.5-34.el6.x86_64
I would be concerned with changing the default value to true in a minor release, or at all for that matter. The specific case where this can be problematic is: >> degraded, but working raid: this is the only case where we would always >> want to have partial_activation=true (or the raid would make no sense) See this bug for a scenario where it is possible to lose data as a result of partially activating volumes: https://bugzilla.redhat.com/show_bug.cgi?id=1251462 The summary is that basically if you have a storage split between nodes of the cluster where each side maintains access to the local site's devices, if the resource then relocates and you activate partially, you can end up using the outdated copy of the data. This will happen silently if you have partial-activation true, and now the new site will be writing its data to a separate mirror copy. At this point you have diverged on both sides in a way that could not be easily merged back together. Perhaps we could give the proper caveats and warnings, but if any customer was using the default value of false to protect from this scenario and suddenly we allow their data to be corrupted, they won't be happy.
Also as this is an RFE, it should probably be closed anyways, given we're into Prod Phase 2. I won't close it myself, since its not customer-initiated.
Closing due to concerns with changing default value for a minor release, and the issues it might cause (see comment #2).