On 12/05/2014 11:39 AM, Gregory Farnum wrote:
On Fri, Dec 5, 2014 at 9:36 AM, Sage Weil <sweil@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
