I prefer the third option (enumeration). I don't see a point where we would enable experimental features on our production clusters, but it would be nice to have the same bits and procedures between our dev/beta and production clusters.
On Fri, Dec 5, 2014 at 10: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?
sage
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
