Re: experimental features

[Mark Nelson <mark.nelson@inktank.com>]

On 12/05/2014 11:39 AM, Gregory Farnum wrote:
> On Fri, Dec 5, 2014 at 9:36 AM, Sage Weil <sweil@redhat.com> wrote:
>> A while back we merged Haomai's experimental OSD backend KeyValueStore.
>> We named the config option 'keyvaluestore_dev', hoping to make it clear to
>> users that it was still under development, not fully tested, and not yet
>> ready for production.  In retrospect, I don't think '_dev' was
>> sufficiently scary because many users tried it and ran into
>> unexpectd trouble.
>>
>> There are several other features we've recently added or are considering
>> adding that fall into this category.  Having them in the tree is great
>> because it streamlines QA and testing, but I want to make sure that
>> users are not able to enable the features without being aware of the
>> risks.
>>
>> A few possible suggestions:
>>
>> - scarier option names, like
>>
>>    osd objectstore = keyvaluestore_experimental_danger_danger
>>    ms type = async_experimental_danger_danger
>>    ms type = xio_experimental_danger_danger
>>
>>    Once the feature becomes stable, they'll have to adjust their
>> config, or we'll need to support both names going forward.
>>
>> - a separate config option that allows any experimental option
>>
>>    allow experimental features danger danger = true
>>    osd objectstore = keyvaluestore
>>    ms type = xio
>>
>>    This runs the risk that the user will enable experimental features to
>> get X, and later start using Y without realizing Y is also
>> experiemental.
>>
>> - enumerate experiemntal options we want to enable
>>
>>    allow experimental features danger danger = keyvaluestore, xio
>>    ms type = xio
>>    osd objectstore = keyvaluestore
>>
>>    This has the property that no config change is necessary when the
>> feature drops its experimental status.
>>
>> In all of these cases, we can also make a point of sending something to
>> the log on daemon startup.  I don't think too many people will notice
>> this, but it is better than nothing.
>>
>> Other ideas?
>
> I don't think these should even be going into release packages for
> users to work with. We can build them on the dev gitbuilders for QA
> and testing without them ever reaching the hands of users grabbing our
> production packages. ;)
> -Greg
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I'm in favor of the "allow experimental features" but instead call it:

"ALLOW UNRECOVERABLE DATA CORRUPTING FEATURES" which makes things a 
little more explicit. With great power comes great responsibility.

Mark