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 <sw...@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? > sage > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
